Just had a chat with another "technologist" (haha) with decades more experience than me about the ins and outs of Mastodon's issues. From technical to social to federated to individual to admin to dev to moderator. Many hours of discussion of all the elements.
We agreed that some form of federal moderation committee is likely a must, as is a standards committee (for dev interoperability).
It's just unsustainable that everyone is essentially communicating primary by shouting over fences.
@Rushyo Even if there was a group tomorrow that was made up of people who truly wanted only the best for the federation and keeping it an open, decentralized platform, isnt it possible that this group could be taken over by people who would abuse it? Wouldnt the better option to be to provide the user tools to moderate their own mastadon experience, or are you talking just moderating the technical side of mastadon.
@BinaryBear There's a huge number of issues at all levels, right now. But, having community representatives actually communicate would serve federation as opposed to merely de-centralised silos. Right now we have a bunch of instances/platforms who only communicate to, essentially, hate on each other. Why not communicate on a regular basis? About other problems? Like adults?
@Rushyo Single spec? Why would you want that? All I said is there are standards. https://www.w3.org/standards/techs/socialweb#w3c_all
@superbranch Why would you want a single spec? Because the pace of change and diversity of user expectations is growing faster than this platform can cope. Mastodon, GS, etc are faster becoming non-interoperable, and the demands and expectations for 'custom features' are rising higher, leading to technical divergence. It's driving wedges in the federated model.
@superbranch This is simply un-true if you look at the Mastodon issue list, and the reasons issues are being rejected. I know my client, like most software, can't function in a word of un-defined specifications where anything could break moment to moment. And it has technical a chilling effect.
@Rushyo I think you can define a sufficiently open standard that encompasses all the standards that are currently out there, but you can't force people to accept it. Federation is about making opportunities to connect, but you still have to put the work in. It's a lot like i18n support.
@superbranch The point is if people are represented in these discussions they won't be 'forced' to accept it, they might actually *choose* to. And then the platforms actually have a base from which to grow, instead of right now where even the basics (should we federate HTML or text?) are subject to dis-agreement, which totally chills the ability to grow and stay connected.
@superbranch The tech is failing to keep up with the change of pace in this society. We need to resolve that. If this is a 'federation', that means federal-level working. If we don't collaborate at a federal level it will cease to be a federation on a technical level, just an archipelago of platform silos, once social progress overtakes it.
I do not imagine that there is only one other possible outcome (GNU vs Microsoft is a helluva false dichotomy here). That would imagine Mastodon + other parties were actively belligerent, w/ had corporate goals to achieve. They don't. They can reasoned with & talked to. They're just other devs like you
@clacke @maiyannah Then give up I guess? *shrugs* if you imagine that other, non-GNU people joining is the end of the road for the principle of openly federating, then you've already "lost" the "battle" by your own reasoning. I think you utterly under-estimate the people involved on the other side of the fence if you can't equate them to anything but a malicious corporation not worth speaking to.
@clacke @twitter @maiyannah I've spoken with the Mastodon dev and their idea of what the spec they are implementing is clearly different to what the GS folks think is the current standard. That's a fact, not me stating an attack on you.
"I'm saying that people who talk like that are not interested in cooperation"
Then, frankly, *you're* being the belligerent fool who can't work with other people who share common goals. Not them
I'm telling you what I know from what I see, from what I am working with.
I'm communicating with you about these things because you and Gargron can't communicate with each other.
I communicate with @mmn about GNU Social stuff, and to figure out implementations which are beneficial on both sides.
Sometimes, we need to deescalate. Which sometimes other people have to step in and help with that.
@maiyannah This is yet another discussion. :)
You're obviously harbouring a lot of bad feelings against Gargron, and I feel like it may cloud the way you discuss these matters a lot of the time. It's unfortunate, but I try to look past it, because I know that what you want to say is actually feature related.
@maiyannah It was not my intention to patronize you, but it is from my experience when talking with you about these things.
Which is why I try to steer around directly talking about certain things, which obviously doesn't always work.
I really just want to be able to have meaningful conversations with you, and for us to be able to build towards common goals.
It can't both be a common de jure spec AND a de facto non-spec as it suits you. Pick one or the other, stop moving the goalposts. Your position is "if it's not GNUSocial" it's wrong. Well what kind of ecosystem do you imagine that is?!
@clacke @twitter @maiyannah That's all I was suggesting. I said I didn't think OStatus was doing it properly, so it should be re-codified with something that works (or, hell, just rally around ActivityPub?) and the people who are then going to be involved in implementing it should all be stakeholders involved in the discussions of how it is performed.
My position can be summed up as simply: Not talking doesn't seem to be working
@twitter @clacke No. I don't understand who or what you've been arguing against in the middle of all this. You've just added some random inflammatory statements in the middle of an otherwise rational discussion. I understand (at least partially) where clacke is coming from, and I'm trying to make myself clearer too, but you are just throwing perpendicular argument grenades in the middle. It's unhelpful AF.
Drivel. I have no interest in dictating who can or cannot. I just think a standard would stop it from fragmenting, as a basic principle. Simple as that.
I don't even agree with Mastodon's approach, y'know. Your "non-GNU, us VS them" sentiment paints a damn broad brush.
If growth of the network were to mean that inevitably the protocols either break compat. or become subject to such an attack, then we can logically derive that federation is a doomed experiment once scaling hits.
I don't think that implied belligerence exists, and I don't think it's doomed.
@Rushyo Thank you for your work. I can't imaging having to deal with a project that took off this crazily. I'm already reeling from the culture shock just as a user. You guys have been far more responsive than I think anyone could fairly expect. Good luck with the growing pains.
@junglestrike Gee. If only I'd already written multiple posts explaining exactly why those things are distinct, in great detail.
You clearly have no intention of doing anything but trying to pick an argument for its own sake, and have no intention of reading the discussion that has already been had because then you're worried you wouldn't be able to pick a fight over it.
@bea Will do. I'm not sure if anything will come of it; I'm just beating a drum about the topic to stir discussion. Partly because I'm not positioned to do so (I'm neither a dev nor admin as I'm too busy with e2e) and partly because I suspect there are people with much better experience/knowledge of how everything jives at the moment, and I'd rather their opinions ultimately came to define any solution over mine.
The key sharing happens off-channel, deriving trust from de-centralised sources and pinning identities.
The reference prototype focuses on messaging over toots via the Mastodon API to other Mastodon API-using clients.
@cs @bea Whole bunch of reasons. Will explain in more detail in an FAQ, but it largely comes down to two things: 1) It doesn't align with Mastodon goals, so where am I going to integrate it? So far the only issue I've raised (optional plaintext messages) to increase stability has been rejected. Utterly impractical to integrate an entire protocol. and 2) The primary threat agent is a malicious admin, who will necessarily be able to ascertain those details anyway.
@lnxw48a1 No, a *federated* moderation committee. As in, a committee of moderators from different instances, who chat to each other from positions of de-centralised authority.
That's completely different from a "federation-wide moderation committee", which would be a central moderation authority.
@Elucidating @lnxw48a1 they don't have to agree. nobody can make people agree in such a setup. either they come to compromises that allow instances to work together, or they do what they'd have done anyway. either there's a compromise the parties can work with, or they go back to square one. nobody's hand is forced.
I don't disagree in principle. I just wonder how to put it in practice in a way that's more valuable than just having the admins talk openly over mastodon itself.
I think there's definitely some lessons to take from that, but they're not very well documented. It's likely we'll just have to re-learn most of them with the aid of the communication tools and knowledge of internet communities we have that people didn't back then. If anyone does know a book I can read, I'd definitely like to hear about it.
(BTW. Anyone wants off this thread train just ask, please!)
@ocdtrekkie @bob @clacke @santa @lnxw48a1 Agreed, to an extent. I think there's a lot of solvable problems we have right now that are only not getting solved because the drivers are really new and different and scary, not because there's inherent differences that make it impossible. To break up the network for that goal seems counter-productive (counter-social), but is always an option.