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.
|
> [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.
|
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.
|
> [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/
|
> [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?
|
#### Q: Can templates be federated or instance-local?
|
||||||
|
|
||||||
> [saunders]: "Template" in the `emmisary` context? Or other?
|
> [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.
|
Goals: Understand current Fediverse norms, pick a viable path, lay groundwork.
|
||||||
|
|
||||||
* Review existing ActivityPub specs
|
- [ ] Review existing ActivityPub specs
|
||||||
|
- Collections, Groups (FEP-1b12), Update/Delete flows, Object types.
|
||||||
Collections, Groups (FEP-1b12), Update/Delete flows, Object types.
|
- [ ] Decide on a Grouping Approach
|
||||||
|
- Evaluate Lemmy/Peertube models
|
||||||
* Decide on a Grouping Approach
|
- Choose between implementing FEP-1b12 or a more custom logic using hashtags
|
||||||
|
|
||||||
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.
|
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.
|
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
|
### Phase 5: Group + Commons Logic
|
||||||
|
|
||||||
Object ID resolution and deduplication
|
|
||||||
|
|
||||||
Propagation of edits (trust-based or rules-based)
|
|
||||||
|
|
||||||
Support federation of UPDATE alongside Create
|
|
||||||
|
|
||||||
Phase 5: Group + Commons Logic
|
|
||||||
|
|
||||||
Goals: Implement logic for groups, commons access, and authorization.
|
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
|
### Phase 6: Trust + Authorization
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Goals: Mediate access to objects based on trust logic.
|
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
|
### Phase 7: Scaling + UX Flows
|
||||||
|
|
||||||
Implement permissions at the object and group level
|
|
||||||
|
|
||||||
UX feedback for permission errors
|
|
||||||
|
|
||||||
Phase 7: Scaling + UX Flows
|
|
||||||
|
|
||||||
Goals: Refine UX and scale up the logic.
|
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)
|
### Phase 8: Application Launch
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Goals: Polish and release a working prototype instance.
|
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
|
- How does our chosen backend implement DB relationships?
|
||||||
|
- Can we implement "groups" using only hashtags and aliasing logic?
|
||||||
Federation with at least 1-2 existing Fediverse projects
|
- How do we scale boolean logic across thousands of hashtags?
|
||||||
|
- What’s the best way to model UPDATE as primary interaction in ActivityPub?
|
||||||
**Developer Questions (Ongoing)**
|
- Can we cache and compress federated flows without breaking expected behaviors?
|
||||||
|
- How to handle clashing edits on shared (commons) objects?
|
||||||
How does our chosen backend implement DB relationships?
|
- What are the best existing tools for ActivityPub testing/debugging?
|
||||||
|
|
||||||
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