Been thinking about [fediverse wiki] after @2chanhaeng@hackers.pub mentioned it today.
Technical Discussion
7
Posts
6
Posters
21
Views
-
Been thinking about fediverse wiki after @2chanhaeng@hackers.pub mentioned it today. Some ideas:
- Cross-instance page linking:
[[Page Title@other-instance.wiki]] - Edit pages on other instances with your home account
- Fork pages across instances:
[[Page@instance-a.wiki]]→[[Page@instance-b.wiki]], sharing edit history up to the fork point
- Merge forked pages later when needed
The fork/merge model feels natural for federated collaboration. Thoughts?
#fediverse #wiki #fedidev #ActivityPub
- Cross-instance page linking:
-
@hongminhee @2chanhaeng Have you heard of ibis? It seems to have already implemented everything you envisioned.
-
@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
-
undefined hongminhee@hollo.social shared this topic on
-
If you're doing
Title@other-instance.wikithat 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 nameto 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.
-
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.
-
@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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
definitely not a fan of this. tbh, there should just not be a global feed that new accounts see, because they see a lot of stuff they don't understand or know the community norms for, and that leads to bad engagement.
-
There is the Web Share API, and the future Web Share Targets API, but I think we could also align Web Share with FedCM and be able to say "I want to share to this type of application"
-
@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666
i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).
-
-
@reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?
Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0
-
With ActivityPub / ActivityStreams...
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
-
@soapdog@toot.cafe hmm... just thinking aloud here.
You posit in another post that the network effects inflate exponentially:
> Push models are resource hogs that approach exponential growth in a large network like the fediverse
That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.
If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!
Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.
If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
-
@evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.
