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
Admin 2025-05-01 19:45:42 +00:00
parent 9e22a04bf4
commit 6a01e002e9
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md

@ -19,6 +19,8 @@ We likely don’t need traditional “groups” in the Facebook sense. Instead,
> [saunders]: I feel like this might be confusing. Do we not need to define "group" with regard to members that come from one or more instances.
> Also we should acknowledge that we're almost certainly using "group" in a different sense to what other fediverse implementations are working on - do we want to find a different term, or try and broaden an existing one?
> [hamish]: yes i would use the word "**flow**", but am getting confused too with the word and implementation of group
#### Q. Is each object still owned by a user? (for federation reasons?)
...but logically "shared" with others via inclusion in a "commons group".
@ -33,6 +35,8 @@ If so, the group becomes an object itself - recursively building a metadata mesh
> Then much like a multitude of replies to a single toot in mastodon can be displayed as a thread in the UI, we could (re)construct a single document to display based on the thread of diffs.
> Am I getting too deep into the weeds too early?
> (hamish]: interesting
#### Q. Collections & storage?
Collections are part of the core ActivityPub spec, but vague in meaning.
@ -54,10 +58,14 @@ Metadata & hashtag logic, hashtags act as the primary organizing mechanism. We a
> [saunders]: Not sure how to go about this. Injecting hashtags feels a bit off. They would have to be somewhat separate from normal hashtag use, but then other fediverse instances would not recognise and them as normal hashtags...
> But if they're intended only for "internal" use and not really for more convential use by e.g. a mastodon instance, then I think it would be fine to store them separately.
> [hamish] maybe we can use the same space but put a different symbol in front - meta data tags - the same function just added by rules not people.
#### Q: Do we need a better metadata field than hashtags? Or can we repurpose hashtags in a way that supports this abstraction?
> [saunders]: Going on my comment above, I feel like maybe we just use a separate field.
> [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.
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.
@ -68,6 +76,8 @@ Templating & UX abstraction, hashtag chaos needs to be hidden (mediated) in the
> [saunders]: Feels like another reason to use a separate data field, and not whatever is currently used for hashtags. That said, we may still make use of normal hashtags for some filtering, as they usually are.
> [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/
#### Q: Can templates be federated or instance-local?
> [saunders]: "Template" in the `emmisary` context? Or other?