A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
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.
Edit: lemmy is actually good now!
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!
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.
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.
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.
I know they will. my instance is going to defederate anyone who tries this immediately.
Meeh, I'll see what happens... though I would prefer to be on an instance that defederated as well.
Exciting time we live in! :)
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.
Its a contravercual idea but it makes perfect sence to me. I fully support this as an excellent compromise
Thank you very much. I was searching for a middle ground or at least a general direction towards it.
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.
In that case: excellent suggestion. :)
Thanks! I appreciate the kind words.
I think these are great rules, so long as they never have any teeth.
Rules without teeth are inherently bad imo.
I don't know if you know this, but Lemmy is also using an altered version of ActivityPub to federate things like downvotes.
Your rules are flawed.
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.
Ah, must have gotten those mixed up then, my bad
No I didnt. Thanks for letting me know.
And my rules are flawed by design. They‘re my first draft. If what I did was perfect I would rule the world, but I am not and nobody is.
Thats why we have democracy. To find common ground. They‘re just an idea, something to help understand an idea and to work off of.
How would these rules be enforced in the first place?
Same answer as before. We would need to find solutions for this as well, together. Thats how teamwork is done.
I‘d say something automatic for things that are pure numbers like the member count. A server is running dozens of operations anyway. If a new server asks for federation, it could get checked for member count and if the count exceeds the arbitrary number (in my example it was 50 or 100 of the rest of the fediverse) the request gets denied.
For more complicated things like pushing ads, one can report a post, moderators bump the report up to the admin and they press „block server“.
Changing the protocol is a little more complicated still. We‘d need to agree what constitutes a „change“, if there are exceptions. Then we‘d look in the logs for suspicious behavior (more like have a script look) and get notified if a server was only sending unusable resonses for certain requests of whathaveyou.
Again, its an idea, something to spark more ideas and lead to more solutions.
The ideas aren't bad, but they need to be broken down into atoms to build a solid foundation for such a rule base.
Before we establish any rules, it might be best to establish a communally agreed set of motivations and goals for the fediverse first.
I am pretty baffled at how genius your questions are. This is exactly what I was hoping to achieve. Spark discussion and ideas.
Rn, my motivation behind the user number is that no single corporation or entity can flood a democratic system, which is by definition then immediately under their control, provided their users are agreeing or being influenced which we have seen time and time again. This is why a large entity would need to break their instances down into smaller instances to avoid this and would need to put them under different management. Same as with the EUs anti monopoly laws. I suppose there could be alternatives. Anyone should feel free to propose them.
Again, an excellent question. I have only thought as far as „this post has been powered by meta, get an account at“ and so on… obviously, there are less overt ways of doing this but for swiftness sake I‘d start with obvious ones and take them out, leave the others until a very good proposal is forming.
The motivation against altering the protocol alone is to keep EEE attacks from happening. So, they can propose a change for all, keep to the agreed solution or leave, imo. That way they are encouraged to argue and not just do their thing. One could say if its open source its still okay bit proprietary is absolute no go.
And yes, I agree full. Feel free to write your own ideas of motivations down so we can discuss them. :)
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“
And thank you. :)
