For example, what would happen if two people change the same paragraph in two different instances at roughly the same time?
This is already a problem for existing distributed versioning systems (like git), and in those the merge conflicts can only happen when the users explicitly request them. With activitypub the merge conflicts would happen in response to asynchronous events and to make things worse, different instances might see different events. How would you surface the conflict to the users so they can solve it? Do you send an email to the user which was a fraction of second late saying their edit got rejected? Do you reject both of them and keep the old content? Do you overwrite the first edit silently?
These are already hard UX problems on centralized wikis, and the technical aspects of a distributed system would make them worse. So much worse that I would say it’s orders of magnitude harder to implement than a link aggregator.
Why would the wiki page have to be decentralised? Each community lives in one instance, the wiki page could similarly be attached to the instance, but with federated users
Why would this happen? Does it have to do with not running the latest software? If so, it seems to me like a responsibility the server admins should be mindful of.
Do you reject both of them and keep the old content?
Why not simply reject both but save them in the history tab and then send PMs to both users involved to inform them of the conflict?
You’re thinking of reimplementing something like git which some wiki open source project might as well already have solved.
So, the answer will be the same: it’ll be better to have a dedicated project/service.
For example, what would happen if two people change the same paragraph in two different instances at roughly the same time?
This is already a problem for existing distributed versioning systems (like git), and in those the merge conflicts can only happen when the users explicitly request them. With activitypub the merge conflicts would happen in response to asynchronous events and to make things worse, different instances might see different events. How would you surface the conflict to the users so they can solve it? Do you send an email to the user which was a fraction of second late saying their edit got rejected? Do you reject both of them and keep the old content? Do you overwrite the first edit silently?
These are already hard UX problems on centralized wikis, and the technical aspects of a distributed system would make them worse. So much worse that I would say it’s orders of magnitude harder to implement than a link aggregator.
Why would the wiki page have to be decentralised? Each community lives in one instance, the wiki page could similarly be attached to the instance, but with federated users
Why would this happen? Does it have to do with not running the latest software? If so, it seems to me like a responsibility the server admins should be mindful of.
Why not simply reject both but save them in the history tab and then send PMs to both users involved to inform them of the conflict?
You’re thinking of reimplementing something like git which some wiki open source project might as well already have solved.
So, the answer will be the same: it’ll be better to have a dedicated project/service.