This is just a soft inquiry for now, but I wanted to open up a discussion about public-facing documentation for the Fediverse: whether it's beneficial to have, what form it should take, and to what degree thorough historical and technical information is needed for preservation and reference.
I've been kind of unhappy with where various Fediverse information projects lie currently, such as the Join the Fediverse wiki. To me, there are a few problems with existing efforts:
- Inherent Bias - Public resources taking a particular biased stance regarding things like competing technologies, what community values should be defined by, or who gets to be counted as part of the Fediverse based on a wide range of assumptions.
- Lack of Organization / Quality Control - Generally, existing community efforts do not pass muster for technical documentation or cultural reference, and instead suffer from poorly-written explanation of what a given platform "is like".
- Lack of Resources (People / Information / Etc) - Could probably fall into the previous category, but compounds problems by generally leading to even higher levels of inconsistency / abandonment.
The thing is, I'm of the belief (maybe delusion) that the wider community would benefit from a dedicated wiki detailing project history, cultural developments, technical insights, and functionally unique spaces within the network. It doesn't necessarily have to be a "here's how to do ActivityPub" guide for developers, or a "here's all the platforms and what they are" dictionary for end users, but I think it might be a useful resource for pointing a lot of different people in the right direction.
Two potential paths
The question boils down to this: hosting a wiki is easy. Cultivating and maintaining one is hard. We (We Distribute) might be in a position to do one of two things:
- Try to support and upgrade a vast body of information on an existing community wiki project.
- Launch our own initiative under the We Distribute umbrella.
I think either one is an initiative worth taking to, but each option has their various benefits and drawbacks. It would be interesting to get insight from the wider community on whether this kind of thing is even wanted or needed, and if so, whether we should spearhead it, or if we should try to improve something that already exists (even if it's bad).
I would love to hear some thoughts from anybody who's interested on the subject.
Very nice that the forum federates with Lemmy now!
This is the first time Im hearing about Hubzilla wiki. The usual request with
curl -H 'accept: application/activity+json'doesnt return any Activitypub JSON, only HTML. Does it really federate, and if so do you know where the wiki federation is documented? Would be good to make it compatible with Ibis.Back to the main topic, a Fediverse wiki sounds like a great idea. Youre welcome to use the main instance ibis.wiki for this, as it is meant for articles about open source software. Or you can host your own instance, the setup is quite simple. It is also possible to move Ibis articles from one instance to another in case you want to try first and launch your own instance later. Let me know if you have any questions!
@[email protected] Thanks for this! We've been considering trying out Ibis, maybe this would be a good chance to review it and report back to you on what the platform's current affordances are, and what we feel like might be missing. Obviously, you don't necessarily want to replicate MediaWiki, but it might be good to see what ideas are worth bringing over.
Yes that would definitely be helpful for the project.
@nutomic It would be very interesting if the Ibis wiki and the Hubzilla wiki could collaborate and sync, which would also make it possible for Hubzilla wikis to sync. Hubzilla already supports ActivityPub so it could communicate with Ibis if set up to do so.
@[email protected] said in this thread that Hubzilla wikis are not federated. Do you have different information?
@nutomic Plus, the fact that we are no longer the only wiki in the fediverse means that there is an incentive to collaborate. Also, you created a new spin on wikis that we did not think about (or if the original developers did think about it, they never implemented it).
Plus if we combined the concepts of a synced federated wiki, with a permission system and federated single sign on, I think we would have a pretty powerful fediverse-powered wiki system.
Ah it sounds like youre a maintainer or contributor on Hubzilla, didnt know that. In fact I am currently working on OAuth-based SSO for Ibis. And making it federate with Hubzilla wikis would definitely be good. For now Ibis doesnt federate with any other Fediverse platforms and has some compatibility problems. In the near future I will make a major rewrite of the federation logic to get that working properly.
@nutomic I mostly work on themes and addons for Hubzilla via Federated Works, but I am also the President of the Hubzilla Association. Mario, Harold, and others maintain the core code. We have a number of initiatives going on right now, such as rewriting the documentation, refactoring the codebase, upgrading the interface, and adding functionality.
@[email protected]
I do not believe that Open Web Auth complies with the OAuth 2 specification. However, there is an FEP for OWA
https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md
@nutomic The wikis themselves are not federated currently. Instead, we used federated single sign on where you can log into someone's wiki and edit it directly.
However, the wikis are stored on a fediverse server that understands federation. All it would take is to tap into the existing federation code to make them federated.
In fact, the wiki pages are currently stored in the same manner as a post, and posts are federated. The only difference is that we don't send out announcements or accept remote edits for wiki pages. But we could if someone wrote that code.
Basically, the infrastructure to make them federated is there, but no one has built that specific functionality yet.
@nutomic Hubzilla takes a very different approach to wikis. Instead of federating the content, the wiki stays with the server, however, since Hubzilla has federated single sign on called OpenWebAuth, you can use your existing OpenWebAuth-compatible fediverse identity to log in and edit the wiki.
This provides a unique permission system where you can grant or deny access to the wiki, and control who can edit it. This means you can create private wikis.
It also have extensive import / export functionality where authorized users can duplicate or migrate the wiki to another server. They would not sync, however.
Adding sync functionality would be an interesting addition, and that could be done in a manner similar to how Ibis does it, but there would be difference, since Hubzilla users can create multiple wikis. It is not one big shared wiki.
@[email protected]
Wiki pages at Hubzilla are unfortunately not federated, but remain on the respective hub.