Forum & Wiki lexicons

[strass]

Hi everyone,

I've been thinking about how to implement forums and wikis within the AtProto ecosystem. These use cases are a bit different from the typical record concepts we work with, as the individual posts or edits are owned by users, while the overall thread or page is inherently owned by the community. This raises a few unique questions about data ownership, management, and moderation.

Currently, I’ve been experimenting with a basic wiki application where users can create, view, and edit markdown articles. Here’s the approach I’ve taken so far:

User Ownership of Edits: Every time a user makes a change, it creates two things:

• An edit in the user’s PDS which contains the full content of the latest revision as well as a patch diff showing what changed since the last edit.
• A new article revision in the appview, representing the updated version of the wiki article.

This structure works for tracking individual edits but introduces a few interesting challenges that I’d love to get some feedback on.

Where should the community-owned content live?
Should the community-driven content (like a thread or a wiki page) exist in a PDS under a community account, or should it reside directly in the AppView? The former might allow better shared access and visibility, but I’m unsure about the best way to balance this with the AtProto model’s emphasis on open access.

Managing URLs/Page Slugs:
Right now, I’m using the rkey for generating page URLs, but this isn't a good solution. How should I handle URLs and page slugs to ensure they are persistent and user-friendly, human-readable, etc?

Race Conditions & Conflict Resolution:
Given the collaborative nature of wikis, how can we best manage race conditions when multiple users are trying to edit the same article at once? I have loose ideas about using Conflict-free Replicated Data Types (CRDTs) but haven't begun to think about implementing it. Has anyone else faced this?

Moderation and Admin Edits:
What’s the best way to handle moderation and admin changes within these types of applications? Traditionally forum admins can edit user posts and wikis have tools to lock pages.

I’m excited to hear your thoughts, especially from those of you who have experience with community-driven apps or complex data structures in AtProto. Any ideas or suggestions are greatly appreciated! Looking forward to the discussion.

Thanks!

[yamarten]

Sorry for the negative comments, but it is quite difficult to build a wiki system on atproto now.

I recommend wait until the shared data system is added. The initial work is expected to take place in the first half of this year. A rough idea can be found here.
Perhaps one account will own articles, and the other will edit it. You may need to do something else to solve the problem of the collision.

This thread may be helpful.

[strass]

Thanks for your thoughts. I'm not sure I'm following because I thought the shared data system was mostly for private data and I was expecting both the edit and the article revision to live publicly.

Are you suggesting that the article, which is community owned, would go in the public repo which is owned by the PDS and not by individual users in the system?

[yamarten]

It's true that if you try to store the editing history, just co-editing is not enough. I expect the possibility that the history function like the public repository in the past will be revived, but even so, it may be more useful to treat the diff as a record in the use case of wiki.

According to the idea of the patch record, I think the latest content should be on the appview (regdless of whether it is in the user repository or not). If multiple appviews appear, different content can be derived from the same records, so appview is responsible for showing the results.

Another point of discussion is that one of the ways to mitigate editing conflicts is that users create records through appview instead of creating records directly on PDS. Uploading videos in bsky is the same as using uploadVideo instead of uploadBlob.
However, in the current PDS implementation by Bluesky, the only API that gives permission to appview is uploadBlob. There is no reason why it is prohibited to pass createRecord permission on the specification, but it is not actually possible.