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.
As we discuss this new ruleset, I think I will leave my instance to start a new one called The United Instances of Lemmy. From this instance I will then half-heartedly yet aggressively send my users to meddle in other instances affairs on my behalf to impose my interpretation of these Fediverse rules without context alongside a few other instances that share my same limited definitions of right and wrong at the expense of everyone remotely involved.
I'm going to start the Confederation of Lemmy Instances, and post a lot of invective about how the confederation is a better approach and people need to leave the United Instances of Lemmy and join the confederation instead. I'll also try to make sure the discussion spills out into as many instances and communities as possible that aren't affiliated with either one of us.
This has already been done. There are already instances with shared, written identities. I know you're trying to portrait it as something horrible but committing to a shared goal is not inherently bad. You could try to actually help people now make the same mistakes again and again.
no Federation with instances that use altered versions or proprietary versions of AP.
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.
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.
I think that having "rules" about who is allowed to federate with whom is antithetical to the open nature of ActivityPub, and I disapprove of any that don't have a purely technical reason behind them.
Which is your right. I stand on the opposite side and say I‘m not federating with „childp*rn.com“ for example. You can do so and tell everyone how you gave the child molesters a chance.
Straight to the child porn, that seems like a new Godwin's law these days.
Obviously any instance can choose to defederate with any other for it's own reasons. I'm talking about protocol rules. Did you see any mention of child porn in them? Going to go yell at OP for supporting child porn too?
no Federation with instances that use altered versions or proprietary versions of AP.
They will try and do this... they might opt to use hooks though... that way, they don't have to disclose source... or will just disclose the changes that add more hooks. What will they be used for? I think we know.
It's an admirable goal, to try and circumvent fighting but I'm just fine with instance users voting their preferences. People are gonna argue no matter what unfortunately. We're a very stupid species, to be honest.
Someone gets the fundamental problem. i'm impressed. :) like the person in a car accident that asks people to help or move out of the way being called bossy afterward. :D
But yes, I'm trying to bring people together. Being upfront and transparent about it seems to be a good way to at least lessen the potential for bad actors to pit us against each other. Call me paranoid but I'm fairly certain we're helping whoever wants the fediverse to fail by getting at each others throats every time a new "giant corporation" or "morally corrupt actor" knocks at our door.
I mostly agree with your rules, they seem well thought out. I have two objections: Firstly altered versions of AP seems hard to enforce. I think if the versions of AP are compatible enough for federation to work, we should let it run.
Secondly, and more importantly, the part were you want to defederate with servers that do not follow these rules is a really bad idea. If some small instance wants to consume the content from threads, their users may still add content to the fediverse. I think these rules would be a good recommendation for any new server admins and committing to these rules would be a good reason to join a server. But I don't see any reason to turn this into a "you're either with us or against us"-type conflict.
I think we're having a misunderstanding here. I dont mean defederate those who do not agree to these rules but those who break them. Like if lemmy world we're to get as big as all other fedi instance, they would need to be defederated as to make them help other instances to grow. Power consolidation is bad and this rule would try to preempt that.
Downvotes federate as Dislike activity which are part of the standard. There are some nonstandard parts eg for locking posts distinguishing comments. But most platforms including Mastodon or Peertube have such custom fields.
This is terrific. Thank you for starting this discussion.
I don't think we can or should wait for individual users to make these decisions. Server admins are the ones who understand the risks and so should make this call. Guidance for server admins based on past experience (cough XMPP!) should be quite welcome.
I might refine the bit about altered API versions to really focus on the real problem: proprietary extensions. We probably want to leave the door open to try out additions to the spec that come with detailed RFCs.
But we know from XMPP that proprietary extensions are a huge problem.
I agree. The „altering“ was meant „without proposing the change to the core protocol“ and as in „doing on your own because you want to be different/working towards proprietary versions“