Moving topics/contexts between communities
Technical Discussion
1
Posts
1
Posters
0
Views
-
Moving contexts (aka topics/threads) between audiences (aka categories/communities) should be something that can be communicated outward.
NodeBB is experimenting with using the
Moveactivity to communicate this to other instances.When a context is moved from one audience to another, the object and all of its descendants go with it. This is communicated with a
Moveactivity with the resolvable context asobject, and withoriginandtargetreferring to the outgoing and incoming audience, respectively.An example
Move:{ @context: <... snipped>, id: "https://activitypub.space/topic/123#activity/move/1761362910015", type: "Move", actor: "https://activitypub.space/uid/1", to: ["https://www.w3.org/ns/activitystreams#Public"], cc: [ "https://activitypub.space/category/1/followers", "https://activitypub.space/category/2/followers", ], object: "https://activitypub.space/topic/1", origin: "https://activitypub.space/category/1", target: "https://activitypub.space/category/2", }The object
https://activitypub.space/topic/1doesn't necessarily mean anything to most implementors, so unless the object domain is yours, you are expected to resolve it to find the root object (and associated context if necessary.)Would adding a new property like
contextRootpointing to the root-level object be useful for implementors?If
targetisnull, theoretically this could signify the removal of a context from its audience.nullvalues are apparently a no-no in AP soRemoveactivity is recommended instead.rimu@piefed.social and nutomic@lemmy.ml melroy@kbin.melroy.org I wanted to ping you all as I am interested in your feedback as I move toward drafting this FEP.
-
undefined NodeBB shared this topic
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@hongminhee @2chanhaeng I see you already got some comments of this nature but was gonna point them out as well. Ibis is the farthest along but Xwiki was the first to add AP to a wiki that I know of. Also Piefed has an added wiki feature for every community but I don't think they federate that part yet.
-
Moving contexts (aka topics/threads) between audiences (aka categories/communities) should be something that can be communicated outward.
NodeBB is experimenting with using the Move activity to communicate this to other instances.
When a context is moved from one audience to another, the object and all of its descendants go with it. This is communicated with a Move activity with the resolvable context as object, and with origin and target referring to the outgoing and incoming audience, respectively.
An example Move:
{ @context: <... snipped>, id: "https://activitypub.space/topic/123#activity/move/1761362910015", type: "Move", actor: "https://activitypub.space/uid/1", to: ["https://www.w3.org/ns/activitystreams#Public"], cc: [ "https://activitypub.space/category/1/followers", "https://activitypub.space/category/2/followers", ], object: "https://activitypub.space/topic/1", origin: "https://activitypub.space/category/1", target: "https://activitypub.space/category/2", }The object https://activitypub.space/topic/1 doesn't necessarily mean anything to most implementors, so unless the object domain is yours, you are expected to resolve it to find the root object (and associated context if necessary.)
Would adding a new property like contextRoot pointing to the root-level object be useful for implementors?
If target is null, theoretically this could signify the removal of a context from its audience. null values are apparently a no-no in AP so Remove activity is recommended instead.
rimu@piefed.social and nutomic@lemmy.ml melroy@kbin.melroy.org I wanted to ping you all as I am interested in your feedback as I move toward drafting this FEP.
-
This does exist, Pleroma has the Message Rewrite Filters or MRF functionality. There's also ActivitySieve or ActivityColander I think it was called, which attempted to do similar.
I've personally been arguing that we need federation management via policies more akin to a firewall: https://writings.thisismissem.social/moving-beyond-the-false-dichotomy-for-federation-management/
-
Though, tbh, someone should probably create a ActivityStreams 2 type for "plain text with facets" where the facets are essentially byte offsets in the plain text, which would enable supporting formatting of course, but also links, mentions, etc.
The content could then still be rendered to HTML, but the source would still be there as an attachment with as plain text + facets + attachments for media.
-
If you're doing Title@other-instance.wiki that seems to imply that you may be doing webfinger to find the article on the other server? I'd probably not recommend this, since article titles can and do change. You'd probably want to define a "search" endpoint on the instance, and then call that, and maybe you'd write it as: [[:other-instance.wiki:Page name#Section name|Displayed text]] where all you need to do is type [[:other-instance.wiki]] and it gives you UI to search for a page name on the other wiki, and automatically fetches the title to display. When you store the page in the database, you'd store the mapping of :other-instance.wiki:Page name#Section name to the Object URI for that page / section. (Since AP objects are only mapped to URIs)
For doing forks / merging, you'd likely want to keep a CRDT of the changes made, e.g., using AutoMerge: https://automerge.org/
Then the edit collection would contain an ActivityPub representation of the CRDT changes, e.g., some serialization of https://automerge.org/docs/reference/documents/rich-text/
That would allow serverA to merge in serverB's edits, even if the article on serverA had been changed.
-
hongminhee@hollo.social There's Ibis
-
@hongminhee @2chanhaeng There is an activitypub application/extension for xwiki https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/
I have no idea how well it works
-
@hongminhee @2chanhaeng Have you heard of ibis? It seems to have already implemented everything you envisioned.
