Open-Media-Network
/
MakingHistory
7
2
Fork 0
Code Issues 1 Pull Requests Releases Wiki Activity

Update Developer Path: Implementing Commons Using ActivityPub, Groups, and Hashtags

master
benpate 2025-05-01 18:34:45 +00:00
parent 17e5259291
commit 7fe6d3f772
1 changed files with 11 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Developer-Path%3A-Implementing-Commons-Using-ActivityPub%2C-Groups%2C-and-Hashtags.md

@ -16,25 +16,34 @@ This resembles a wiki-like system within ActivityPub, but with trust-grouped, ha
Each object is still owned by a user? (for federation reasons?), but logically "shared" with others via inclusion in a "commons group". Q: Can a “group” just be a collection of hashtags with boolean logic applied? If so, the group becomes an object itself—recursively building a metadata mesh.
Q. Collections & storage? Collections are part of the core ActivityPub spec, but vague in meaning. Some are ordered (e.g., outbox, followers). Others are unordered or conceptual. Collections seem to be API-level constructs, not strict data models.
Q: Collections & storage? Collections are part of the core ActivityPub spec, but vague in meaning. Some are ordered (e.g., outbox, followers). Others are unordered or conceptual. Collections seem to be API-level constructs, not strict data models.
(Ben): ActivityPub is just the "protocol" - so Collections are just how records are represented in places like an actor's outbox. Most implementations use `OrderedCollection`s for just about everything, with un-ordered collections just being left unused in the spec. In Emissary, these records are stored in MongoDB. These map (nearly) 1:1 with ActivityPub collections, but there are differences, such as the extra data that Emissary stores but does not represent via ActivityPub.
Q: Is this table structure scalable for thousands of hashtags/groups? The heavy lifting of flows can be handled by back-end logic.
(Ben): I believe so. This specific code hasn't been tested with more than a few thousand records in each MongoDB table. But, MongoDB is built for high-capacity and high-volume datasets. I think we'll be in good hands here.
Federation logic & edits, object ownership still belongs to the originating account/instance. Others in the trust group can edit via the ActivityPub Update verb. This is different from the usual Comment/Reply flow. The system needs history/versioning of objects like a wiki.
(Ben): Agreed. Emissary doesn't currently support this kind of workflow, but I'd like to see how possible it is. I have reached out to the developer behind Ibis Wiki to see if he has any suggestions on how we can accomplish this, too.
Q: How does current Fediverse federation handle Update? Does it propagate changes cleanly? What do Lemmy, Peertube, etc. do here?
(Ben): Every system works a little differently. There are some common data elements that are nearly universal, but then each system has its own extensions. It's hit-and-miss for many kinds of interop. Check out [Fediverse Enhancement Proposals](https://codeberg.org/fediverse/fep) for some examples of the different extensions that everyone is supporting. Since each app has a different target and feature set, the question is "what do you want to sync to Lemmy/Peertube users?" -- probably just *the fact* that this record exists (or has changed) but not the actual changes themselves. A Peertube user can't edit a Wiki article from Peertube itself, they'll need to bounce over to the wiki to do it.
Metadata & hashtag logic, hashtags act as the primary organizing mechanism. We avoid enforcing a single tag; instead, instances can alias/group tags (e.g. treating #openweb, #4opens, #fediverse as equivalent in one context). This can be done by injecting additional hashtags via trust-logic (i.e., metadata layering). Injected hashtags must not appear as user-authored. Display should abstract hashtags in the UI - show clean flows, not cluttered tags.
(Ben): I'm interested to explore this with you. I've built some interesting Hashtag filters for Bandwagon. In short, users can hashtag anything they want, but server admins choose which ones will work in the global search, and which ones get banned. I can walk you through this, if it's helpful. And, if you have more sophisticated ideas on managing hashtags better, I'm happy to incorporate this into Emissary itself.
Q: Do we need a better metadata field than hashtags? Or can we repurpose hashtags in a way that supports this abstraction?
(Ben): Emissary has rudimentary support for different "flavors" of hashtags -- though I haven't really used this to its full potential yet. As an example, Bandwagon.fm uses different flavors of hashtags to represent: Genres (rock, pop, jazz, etc), Moods (cozy, party, sleepy, etc) and Instrumentation (Guitar, Piano, Violin, etc). Perhaps there's a way for us to use this hashtag hierarchy in the Wiki project as well.
Trust & authorization flows, only people in a trusted group can edit an object in the commons. Others can view/comment but not edit. Trust flows are likely to diverge into subjective consensus spaces - and that’s fine.
(Ben): This is good. Emissary has some strong user permission controls in place now, though this may be difficult to manage if we allow distributed edits. One thought here: this might work if ActivityPub is used to push COPIES of an article to external servers, but EDITS/UPDATES to the original must always be done on the original server. As in Git, external servers might choose to FORK a piece of content, but would then no longer get updates from the original. Just a thought.
Q: How is authorization defined and verified across instances?
(Ben): We could use OAuth for this. Emissary has nascent support for OAuth, and we could expand this to allow someone to verify themselves via their home server.
Templating & UX abstraction, hashtag chaos needs to be hidden (mediated) in the UI with templated displays. Instances could share templates for rendering object streams. We’ll need a UX spec for how to display, merge, or alias tags and flows.
Q: Can templates be federated or instance-local? What’s the minimum needed to keep UX in sync?
(Ben): Templates are under the control of the server admin, and must be installed on each instance. For two instances to Federate the same kind of content, they should probably install the same sets of templates. Templates can be published via Git, and other common file systems, but there's no automated way to push them to other servers (and it would probably be a security risk if we tried to allow it)
Scaling Considerations:
@ -47,6 +56,7 @@ It gets meta and messy, but ActivityPub supports it in theory.
We need to measure early performance scaling under large flows and tag aliasing.
Q: What flows (hashtags, groups, trust edits) are most likely to create bottlenecks?
(Ben): The biggest bottlenecks are likely to be interoperability with other apps. It's "easy" to interop with other servers running your own software. But it's hard to make messages that are recognized by all the crazy permutations out there on the Fediverse.
Developer Questions: