Update Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags
mj-saunders
parent
992363fdf7
commit
9ed1db22be
|
|
@ -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?
|
||||
- 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?
|
||||
Loading…
Reference in New Issue