Allow viewing of public Org files and repositories

[zaz]

Problem

No way to view public org repositories. Even if I log in to GitLab, it seems I cannot even view a public repository in Organice unless I have write access; I get the error "Failed to access GitLab project - is the URL correct?"

I want to collaborate with non-emacs users by sharing an org file in a way that allows viewing it without logging in, and editing with log-in. Export to HTML achieves the former. Organice achieves the latter.

The simplest existing solution to both that I am aware of would be: Push to GitLab and setup a CI pipeline that then exports the Org file to HTML and publishes it to a website. That website then links to Organice where people can edit the Org file (after manually inputting the URL of the repository and logging in).

Solution

Add separate options to view public repositories instead of logging in. This should result in a GET request, so that users can directly link to a repository and a specific org file viewable in Organice. Users should also be able to link directly to a private repository.

This could make Organice the simplest solution to share an Org file with non-emacs users.

Alternatives

Potentially modify the OAuth process to add an option "do not sign in". Or, potentially separate the authentication mechanism from the rest.

Additional context

This requires changing the URL structure of Organice, but it may result in some simplifications. For example, https://organice.200ok.ch/sample will no longer be a special case, it will simply be treated the same as any other link to a public Org file.

I am willing to work on this. Any pointers are welcome.

[munen]

Hi @zaz

Thank you for reaching out 🙏

You make an interesting proposal! I can relate wanting to share Org files with non-Emacs users. I have two use cases for that:

1. In a project where I'm PM, I have regular meetings with the stakeholders and manage the issues. The other stakeholders should have read-only access to the Org file. At 200ok.ch, we do this regularly. For that, we export the Org file to HTML, add https://orgmode.org/worg/code/org-info-js/ and put the HTML file behind HTTP basic authentication.
2. In a project with multiple stakeholders where everyone should have write access. These projects are always of a private nature (both for professional and personal projects), therefore they are always behind a login.

If I understand you correctly, you are proposing a third option: A project with multiple stakeholders where everyone can manage the Org file, but should not have to log in. I am uncertain how you want to achieve rw access to a Gitlab repository without logging in. Does Gitlab offer an API for that?

More generally speaking, iirc, this feature relates more to the functionality of the back-end than for organice. Therefore, organice already does support what you want. You can set up a WebDAV server with rw permissions, but without login credentials. The repo includes an Apache server with such a configuration. You can find the documentation here: https://organice.200ok.ch/documentation.html#faq_webdav

What would still be missing is the ability to link to the file and having the information about the back-end strategy (WebDAV in this instance) and the repository.

---

If you wanted to change organice so that you can link to a file and organice opens it in a read-only manner (which would be akin to the /sample file exception and to use case 1 from above, this could be very interesting as well.

---

Let me know your thoughts on the questions above. If you proceed with developing this new feature set, I'm happy to provide additional pointers and help with testing/documentation.

[zaz]

Apologies for not being clear.

If you wanted to change organice so that you can link to a file and organice opens it in a read-only manner (which would be akin to the /sample file exception and to use case 1 from above, this could be very interesting as well.

This is what I meant.

The rationale for this feature would be a project with multiple stakeholders where some people have write access and everyone has read access.

So what I'm proposing is: When you give Organice a URL, it loads that URL as an Org file. If authentication is required to read the file, it prompts the user for authentication. Then, if the user has write access, it enables editing features.

I'm thinking Organice could become useful to a wider community if it provided a way to link to Org files. E.g.

https://organice.200ok.ch/urn#https://writequit.org/denver-emacs/presentations/files/example.org

Would show a pretty, formatted version of https://writequit.org/denver-emacs/presentations/files/example.org

So if I want to share an Org file with someone, I now have two options:

1. Export it to HTML and publish it on the web, or
2. Publish it on the web verbatim and then link to it via Organice

[munen]

Hi @zaz

Apologies for not being clear.

No worries. You probably were and I just misunderstood(; Now that I understand your proposal, I like it very much and agree with your assessment of the benefits! I also like your proposal for the URL scheme.

The last topics to discuss before implementation are imo:

1. If authentication is required to read the file, it prompts the user for authentication.

   I'm assuming you are referring to the file being behind a HTTP basic auth scheme. If organice prompted for the credentials, that would be very nice, indeed.

2. UX. organice currently inherently is an editor, not a viewer. There are already two exceptions to this rule:

   1. The /sample file. When this file is opened, the user does have all functionality, but there's no persistence. Basically, it's for playing around.
   2. The /changelog file. When this file is opened, the user has very little functionality. The file is rendered as usually, but only opening and closing of headers works. Menus enabling other functionality are not shown.

The question is how to work for a PM read-only use case as described by you. Implementing the /changelog option is easiest. However, some features of organice are reasonable in a read-only use case. Those would be lost. Going the /sample way seems unreasonable. It'll give the impression to the user that she can edit the file when she cannot. So I see these paths going forward:

1. Using the /changelog way for your proposal.
2. Creating a new option where read-only files (possibly including the /changelog) are presented with the options that make sense for a read-only case. Searching, focusing and exporting to email come to mind.

[munen]

For future reference, I have added an ADR on how to implement a new synchronization back-end: https://organice.200ok.ch/documentation.html#adr-003