@rysiek @david_ross I was like "why would Signal federate, it's being run by a company after all" then looked it up on the wikipedia, and it turned out OWS is running from donations... but it's not a non-profit, and from what I've seen, it's acting like a for-profit company... dunno what to think about it...
@Wolf480pl @david_ross this is Moxie's reasoning: https://whispersystems.org/blog/the-ecosystem-is-moving/
@Wolf480pl @rysiek @david_ross it's not even five years ago when we had a xmpp deployment within a single company and you couldn't depend on it to deliver messages, not to ever mention luxuries like voice (lol) or sending files (lol^2), because it just didn't ever work properly no matter what you tried, even when you could fix a particular issue on hand, next day, there would be another and then another, neverending stream of broken shit
moxie is right
With whatever "content policies" you're proposing, at least you would see it, before any kind of content policies took care of it.
The harm to you is the same. You saw the spoiler you didn't want to see. Because there was no CW.
i think you can have a system you control on a technical level and define its boundaries and live happily
you think... you need to make people do "the right thing"? pick the right clients? or what exactly?
@Wolf480pl @rysiek yeah, and now we could think about what twitter or other tightly coupled network could do that mastodon/fedi can't... or what tools twitter already has... to which anyone can reply that maybe fedi could, if they could agree, and everyone implemented it... and there we are back where we started... and where i find a contradiction.
Srsly tho, I can see several ways to deal with them:
- every affected user just blocks that account (implemented)
- an affected instance filters out that account from their federated timeline (implemented in Mastodon, not in Pleroma AFAIK)
- an affected instance completely blocks that specific user (AFAIK not implemented yet, could be done by any instance alone, w/o protocol change or coordination)
- federated abuse reporting (AFAIK not implemented yet)
You can run your own fork on your server and it will still be able to communicate with other servers.
But your server will be better - it will have polls. So if polls really are better, people will slowly migrate to you, or run their own instances of your fork.
If it wasn't federated, your fork wouldn't be better, because if I was using your fork, I couldn't communicate with the rest of the network.
But it's all federated, so I lose nothing by moving to your instance.
@Wolf480pl @rysiek @david_ross sure, but fixable how? there's no way to make xep's non-optional in any sane way, all that xmpp is a very poor text messaging protocol with a lot of optional stuff on top, you can say, so go ahead and use this one good xmpp client and one good server, but thx, we already did this by picking up a different good protocol and client and we just don't care, because, well, why?
1. you agree on which XEPs should be supported by everyone
2. you take some of the funding that goes to Open Whisper Systems and give it to XMPP client and server devs who get no funding whatsoever
3. you make an automatic test suite that checks which clients and servers support which XEPs, and make it generate a public website with a leaderboard of clients and servers with best conformance.