It would be a nightmare to implement a wiki over activepub, so it would probably need to exist outside of federation.
It also feels like the kind of feature creep that made Reddit unsustainable. Software should do one thing and do it well - Reddit’s reliance on 3rd parties fixing core functionality while they pursued every shiny new thing their product managers and software engineers wanted to put on their CV should be a cautionary tale.
I feel we would be better served with wikis stored outside of Lemmy and simply linked in the description. Lemmy exists on the web and shouldn’t try to pretend it doesn’t like corporate social media.
Sorry for my ignorance but why would it be a nightmare to implement over Activitypub? Would there be an issue with approved editor accounts from other instances?
I don’t know if I would consider wiki pages the threshold for feature creep. It’s been a basic feature for Reddit mods ever since I joined Reddit 10 years ago. Therefore it existed before all the new.Reddit features were thrown in. Mods use wikis for directories, tutorials, archiving select content, and bot configs. Yes you could link to external wiki pages but IMO the experience for reading, editing, and adjusting settings would not be as seemless.
Sorry but I fail to see why support for wikis would be synonymous with corporate social media. IMHO, it’s a fundamental tool to have.
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?
It would be a nightmare to implement a wiki over activepub, so it would probably need to exist outside of federation.
It also feels like the kind of feature creep that made Reddit unsustainable. Software should do one thing and do it well - Reddit’s reliance on 3rd parties fixing core functionality while they pursued every shiny new thing their product managers and software engineers wanted to put on their CV should be a cautionary tale.
I feel we would be better served with wikis stored outside of Lemmy and simply linked in the description. Lemmy exists on the web and shouldn’t try to pretend it doesn’t like corporate social media.
Sorry for my ignorance but why would it be a nightmare to implement over Activitypub? Would there be an issue with approved editor accounts from other instances?
I don’t know if I would consider wiki pages the threshold for feature creep. It’s been a basic feature for Reddit mods ever since I joined Reddit 10 years ago. Therefore it existed before all the new.Reddit features were thrown in. Mods use wikis for directories, tutorials, archiving select content, and bot configs. Yes you could link to external wiki pages but IMO the experience for reading, editing, and adjusting settings would not be as seemless.
Sorry but I fail to see why support for wikis would be synonymous with corporate social media. IMHO, it’s a fundamental tool to have.
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?