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

master
Admin 2025-05-01 07:37:44 +00:00
parent 92a789c935
commit 8a4d624a37
1 changed files with 79 additions and 0 deletions

@ -0,0 +1,79 @@
Developer Path: Implementing Commons Using ActivityPub, Groups, and Hashtags
Were exploring how to use ActivityPub for federated, editable content in a "commons" structure. The aim is for data objects to be:
Pushed by a user account,
Placed in the commons,
Editable by trusted groups,
Organized by hashtags,
Federated across instances.
This resembles a wiki-like system within ActivityPub, but with trust-grouped, hashtag-driven object flows. Groups as Commons? We likely dont need traditional “groups” in the Facebook sense. Instead, collections of hashtags, and logic based on hashtags can act as implicit groups.
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: Is this table structure scalable for thousands of hashtags/groups? The heavy lifting of flows can be handled by back-end logic.
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.
Q: How does current Fediverse federation handle Update? Does it propagate changes cleanly? What do Lemmy, Peertube, etc. do here?
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.
Q: Do we need a better metadata field than hashtags? Or can we repurpose hashtags in a way that supports this abstraction?
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 thats fine.
Q: How is authorization defined and verified across instances?
Templating & UX abstraction, hashtag chaos needs to be hidden (mediated) in the UI with templated displays. Instances could share templates for rendering object streams. Well need a UX spec for how to display, merge, or alias tags and flows.
Q: Can templates be federated or instance-local? Whats the minimum needed to keep UX in sync?
Scaling Considerations:
Everything becomes a data object: posts, groups, tags, users.
Each has their own flows, metadata, and permissions.
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?
Developer Questions:
How are you currently handling group logic? Do you use ActivityPub collections or something custom?
How do you store and retrieve group-object relationships in the database?
Are hashtags treated as first-class group indicators?
How does your system manage Update verbs and object versioning?
Do we have support for metadata (like added hashtags) in a way thats distinct from user-generated content?
How is authorization for edits determined and verified?
Can we understand how the system would scale with thousands of hashtag-defined groups and flows?
Need a session for mical to understand the template system for UX rendering of objects or flows?
Next Steps
Define minimal data schema: objects, groups, tags, flows, users.
Prototype Update logic with versioning.
Test tag-aliasing with injected metadata.
Write draft UX spec for hashtag/flow abstraction.
Implement basic trust-group logic using existing ActivityPub verbs.