Disclaimer
I‘m not asking if you want to federate or not and why. The question is if a defined ruleset would make it more transparent for everyone and more future proof.
Since we are seeing major divides due to the (de)federation of threads and now the federation of flipboard, we might wanna discuss future rules so to not fight about everything.
I can see arguments for both sides but some of the technical ones are more compelling since peeps who are unhappy can always move, an overextended instance will have to close. So I‘d take this as the basic principle:
- no federation with instances bigger than half the fediverse (arbitrary number, could be no bigger than all of it as well)
- no federation with instances that push ads with their posts
- no Federation with instances that use altered versions or proprietary versions of AP.
- no one way federation
These are obviously just ideas. There are several „unions“ of instances already that implement more or less of these ideas but I think its something that should be discussed instead of just yes or no.
Also, I‘d suggest we make such rules permanent as in if any instance changes in this way, it gets auto defederated.
This would make interaction more clear and easy for users to choose their instance. For example, If someone wanted the possibility of twitter federating, they‘d not go to an instance that has this ruleset.
Any other ideas?
It’s especially funny given (the last time I checked) neither kbin nor lemmy actually followed the spec properly. They ignore the jsonld requirements and resort to field names, that, by the spec, should be dropped.
The spec allows using plan JSON for Activitypub.
https://www.w3.org/TR/activitypub/
But lemmy doesn’t use “plain json”, it annotates some fields with the schema, just not all of them, which makes it a mess. You either do json-ld proper, or you don’t do it at all.
All of the fields should be defined in context. Which one do you think is missing?
I took a look at the current traffic and you’re absolutely correct, lemmy (as of 0.19) has a proper schema with everything covered!