Real Time Collaboration beta.69

[tangjeff0]

edit: @Limezy wrote a comprehensive post on web vs desktop vs mobile, which encompasses RTC : #737 (comment)

Discussion for https://github.com/athensresearch/athens/releases/tag/v1.0.0-beta.69

Next steps are to work out kinks and map out the primary use cases and user journeys. I see 3 primary use cases.

least technical, most convenient <-1-------2-------3-> most technical, least convenient

1. SaaS

• e.g. Notion
• User doesn't necessarily know what open-source is, and does not use primarily Athens because they value privacy or the ability to introspect and modify the source code.

2. 1-Click Deploy

• e.g. Heroku
• User wants to run a custom version of Athens, but wants more control over the infrastructure.
• Potentially a gateway into 3? To test out how easy self-managing is.
• Perhaps a developer, but doesn't want to read docs.

3. Self-managed

• e.g. On-Premise
• User wants to run Athens on their own hardware. No part of their stack can be in a public cloud
• Definitely a developer, but willing to read docs

[gilbert0007]

Copying from discord

By web-hosted you mean like you guys will be making your own website like roam research?

So what makes collaboration on web-hosted different/difficult from self-hosted?

How did you solve the conflict problem that arises while collaboration? Is it solved because the database is linearizable, meaning DB accepts transactions one at a time?

why can't this (self+hosted collaboration) solution be used in web-hosted?

[Limezy]

Hi @tangjeff0, I'm a bit confused here :

Are you trying to brainstorm about typical users of a web-based Athens, or about typical users of a web web-based real-time collaboration backend for Athens ?

I can see a lot of use cases, as somebody may want to use a desktop app but with a web-based Athens backend (SaaS or self hosted). Somebody may want to use a web-based Athens frontend + backend (SaaS or self hosted) but doesn't care about real time collaboration and so on...

[tangjeff0]

That's a very good point -- some users may want web-based Athens without real-time collaboration. But why would they want that? Here are some reasons I can imagine for why a user might not want to install a desktop app and instead use a web app:

1. They are using another computer temporarily
2. They want to use mobile browser (assuming we don't have a mobile app yet or they don't want to download it, and assuming our web version is mobile friendly!)

[DominicChiampi]

My use case definitely falls into number 3. I want to create a shared knowledge graph for the developers at my job. I think the biggest challenge is going to be onboarding people. I can imagine a bunch of people being as clueless as I am (WRT PKM) creating a spaghetti mess of nonsense.

I am open to suggestions on other models here, but talking a little bit with @shanberg I came up with a loose framework that would work for my use case. There would be "layers" of pages. The bottom layer is completely open -- anyone can create and edit these pages.

The middle layer is curated domain knowledge documents. Ideally relevant developers would take ownership of these pages. I think these pages should have some function where changes can be suggested by anyone and then optionally merged by the owners. For example, I would own a page on Docker and how we use it in our stack. Individual developers may experiment with their local environment and find something worth putting into the core knowledgebase. Some way for me to easily review and add their contribution to the page I own would be ideal.

The top layer is purpose driven admin-level documents. In order to make the knowledge graph usable for everyone (maybe even our non-technical writing staff?) there would be a single entrypoint to the graph. That entrypoint would point in different "directions" and those directions would branch out to the area knowledge pages, which someone could follow the links to the bottom level pages to get the full context or raw information from relevant notes.

Supporting OAuth2/OIDC for authentication and roles/scopes/whatever the proper term is for authorization would be the easiest to integrate.

Following is a list of things that I think are totally unnecessary for me to getting a shared graph up, but I would like to have:

• a way to load multiple graphs so I can read my own graph while curating the shared work graph
• a way to multi-home pages across graphs -- if the "Docker" page in the shared graph is updated, update it in my graph
• ideally the multi-home tools would be extremely granular -- I may have good bits in my graph that fit perfectly into the shared graph, but those bits are immediately adjacent to things that are personal opinions that I don't want enshrined into workplace documentation. If that's too abstract, I can come up with a concrete example.

[DominicChiampi]

Related to multiple databases, a setup where I have a personal-personal, personal-work, and shared-work db would be ideal. I might want to share my personal-work db with my team without needing it to be edited for addition to the shared graph.