diff --git a/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md b/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md index b65b7db..aee383b 100644 --- a/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md +++ b/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md @@ -66,6 +66,8 @@ Metadata & hashtag logic, hashtags act as the primary organizing mechanism. We a > [hamish] they have exactly the same function, so for cross federation, we don't have control how they are displayed or used so might as well just show them all. +> [saunders]: How many tags might collect on any one object? If it gets to tens, let alone hundreds or thousands then displaying them in a "traditional" way would be horrendous. + 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. > [saunders]: We need to clear up the ambiguity between group as a set of people vs group as something determined by a set of hashtags. @@ -78,6 +80,8 @@ Templating & UX abstraction, hashtag chaos needs to be hidden (mediated) in the > [hamish] the is a difference between category and hashtag, one is vertical one is horizontal, we do the horizontal, even if its a bit of a bodge. https://hamishcampbell.com/federating-metadata-flows-bridging-folksonomy-and-categories-for-the-omn/ +> [saunders]: I don't see where categories come into this yet. "hashtag chaos" is what I was considering. + #### Q: Can templates be federated or instance-local? > [saunders]: "Template" in the `emmisary` context? Or other? @@ -128,115 +132,84 @@ We need to measure early performance scaling under large flows and tag aliasing. ---------------------- -DRAFT - OMN Commons System — Developer Roadmap +## DRAFT - OMN Commons System — Developer Roadmap -Phase 1: Foundations +### Phase 1: Foundations Goals: Understand current Fediverse norms, pick a viable path, lay groundwork. -* Review existing ActivityPub specs - - Collections, Groups (FEP-1b12), Update/Delete flows, Object types. - -* Decide on a Grouping Approach - - Evaluate Lemmy/Peertube models - - Choose between implementing FEP-1b12 or a more custom logic using hashtags +- [ ] Review existing ActivityPub specs + - Collections, Groups (FEP-1b12), Update/Delete flows, Object types. +- [ ] Decide on a Grouping Approach + - Evaluate Lemmy/Peertube models + - Choose between implementing FEP-1b12 or a more custom logic using hashtags -* Phase 2: do a working version using Emissary +### Phase 2: do a working version using Emissary - -* Phase 3: Core Object Model +### Phase 3: Core Object Model Goals: Build basic ActivityPub-compliant object handling. -Implement UPDATE as primary user interaction +- [ ] Implement UPDATE as primary user interaction +- [ ] Implement object history/versioning (wiki-style) -Implement object history/versioning (wiki-style) - -Phase 4: Federation +### Phase 4: Federation Goals: Federate content using ActivityPub, handle common verbs. -Outbox/Inbox endpoint logic +- [ ] Outbox/Inbox endpoint logic +- [ ] Signature validation and auth +- [ ] Object ID resolution and deduplication +- [ ] Propagation of edits (trust-based or rules-based) +- [ ] Support federation of UPDATE alongside Create -Signature validation and auth - -Object ID resolution and deduplication - -Propagation of edits (trust-based or rules-based) - -Support federation of UPDATE alongside Create - -Phase 5: Group + Commons Logic +### Phase 5: Group + Commons Logic Goals: Implement logic for groups, commons access, and authorization. -Group object model (as virtual objects or ActivityPub actors) +- [ ] Group object model (as virtual objects or ActivityPub actors) +- [ ] Implement group membership flows +- [ ] Store group-object relationships in DB? +- [ ] Boolean logic for hashtag-group relations +- [ ] UX: Display objects by hashtag flow + group context +- [ ] Define “Commons” group as a writable shared space -Implement group membership flows - -Store group-object relationships in DB? - -Boolean logic for hashtag-group relations - -UX: Display objects by hashtag flow + group context - -Define “Commons” group as a writable shared space - -Phase 6: Trust + Authorization +### Phase 6: Trust + Authorization Goals: Mediate access to objects based on trust logic. -Define and store "trust flow" data (user-group relationships) +- [ ] Define and store "trust flow" data (user-group relationships) +- [ ] Build auth logic for edit vs. comment rights +- [ ] Implement permissions at the object and group level +- [ ] UX feedback for permission errors -Build auth logic for edit vs. comment rights - -Implement permissions at the object and group level - -UX feedback for permission errors - -Phase 7: Scaling + UX Flows +### Phase 7: Scaling + UX Flows Goals: Refine UX and scale up the logic. -Metadata injection via instance logic (e.g. grouping hashtags) +- [ ] Metadata injection via instance logic (e.g. grouping hashtags) +- [ ] Display hashtags abstractly (UX templating of messy tags) +- [ ] Optimize object retrieval (object IDs by group → fetch only needed) +- [ ] Caching and pagination for large flows +- [ ] Tag aliasing/grouping UI tools -Display hashtags abstractly (UX templating of messy tags) - -Optimize object retrieval (object IDs by group → fetch only needed) - -Caching and pagination for large flows - -Tag aliasing/grouping UI tools - -Phase 8: Application Launch +### Phase 8: Application Launch Goals: Polish and release a working prototype instance. -“MakingHistory” and “Indymedia” themed templates +- [ ] "MakingHistory" and "Indymedia" themed templates +- [ ] MVP instance of federated “commons” publishing +- [ ] Simple mobile-first UI with edit/comment modes +- [ ] Editable content histories +- [ ] Federation with at least 1-2 existing Fediverse projects -MVP instance of federated “commons” publishing -Simple mobile-first UI with edit/comment modes +## Developer Questions (Ongoing) -Editable content histories - -Federation with at least 1-2 existing Fediverse projects - -**Developer Questions (Ongoing)** - - How does our chosen backend implement DB relationships? - - Can we implement "groups" using only hashtags and aliasing logic? - - How do we scale boolean logic across thousands of hashtags? - - What’s the best way to model UPDATE as primary interaction in ActivityPub? - - Can we cache and compress federated flows without breaking expected behaviors? - - How to handle clashing edits on shared (commons) objects? - - What are the best existing tools for ActivityPub testing/debugging? \ No newline at end of file +- How does our chosen backend implement DB relationships? +- Can we implement "groups" using only hashtags and aliasing logic? +- How do we scale boolean logic across thousands of hashtags? +- What’s the best way to model UPDATE as primary interaction in ActivityPub? +- Can we cache and compress federated flows without breaking expected behaviors? +- How to handle clashing edits on shared (commons) objects? +- What are the best existing tools for ActivityPub testing/debugging? \ No newline at end of file