[neonsunset]

Weak technology stack and deeply flawed concept of federation that enables local centralization of control by discord-mods-meme style with all the corresponding issues.

Mastodon should have been based on DHT with each "terminal" aka "profile" having much higher autonomy.

Otherwise, it just gives more tools to people who left Twitter to continue doing same societal damage.

p.s.: it is time to stop writing back-ends in Ruby when every other popular alternative (sans Python-based ones) is more powerful and scalable.

[denysvitali]

IMHO decentralization is not the way to go, which is why I started OpenDolphin [1].

If you end up having a "decentralized system" with 30k users per instance, you basically just have a centralized system that federates with other instances. Sure, it is kind of decentralized, but the admins of that 30k instance are effectively able to read the DMs, impersonate users and delete their content.

I personally think (and I'm trying to formalize my ideas somehow with OpenDolphin) that a centralized instance that is only used to serve the __signed__ / encrypted content solves some parts of the decentralization issues we're seeing here - whilst still giving the users some of the features of decentralized platforms.

If you like / dislike the idea, help us out! We're trying to build a community to build together something great. Every contribution counts (:

And btw, yes, I do agree: that hardware for 30k users doesn't make any sense - it really shows that something isn't optimized :(

[1]: https://about.opendolphin.social/

[vidarh]

A centralised instance of any kind is a non-starter for a lot of those of us who have moved to Mastodon. And, yes, the admins of that 30k instance is able to do all kinds, and their users are able to leave if they do. I'd be all for improvements around signing and encryption, but not at the cost of centralisation (for my part, I run my own Mastodon server, but is also tinkering with my own ActivityPub implementation).

[denysvitali]

Care to elaborate what could be the reason why a centralized instance is a non-starter? It looks like Mastodon's approach is yes decentralized, but soffers from the same censorship issues like Twitter - instances are often blacklisted on Mastodon

[vidarh]

Because if I wanted that just stay with Twitter, and that's the attitude of a lot of us.

I run my own instance. I can't do that on Twitter. If I get tired of it, I can move to another instance and most of my followers will migrate automatically (not all, yet, because not all ActivityPub software supports the move mechanism, but when I moved to my personal instance 80%+ already moved automatically, and it'll go up).

Instances can be blacklisted on Mastodon, but have far less of an impact unless you're so particularly abuse that a large portion of the network blocks you.

If you don't provide means to do robust blocking and moderation that will be another reason for people to stay away. Mastodon has these "issues" because it is what users want. Anyone can say exactly what they want, but anyone can also choose to block you, or your instance, if they don't want to listen. Gab is an example that is on Mastodon and is widely blocked because most people don't want to interact with them, and that's our right, but they're still free to talk to those who want to deal with them.

[ilyt]

Users choosing to block someone vs server admins deciding to decide for their users to block whole other server.

It would be fine if it was just "don't pull this server to public feeds", but as it is now it just repeats the problem of giving moderators too much power over users.

[vidarh]

It can be just "don't pull this server to public feeds. In fact it can be a lot more granular. You can:

* "Silence" it - makes posts invisible on your instance for everyone not following them * "Suspend" - removes all content. * Reject media files. Avoids downloading media files locally from this instance. * Reject reports from instances that are abusing the reporting.

But limiting an instance is often insufficient because it doesn't stop your users from then subsequently replying etc. and indirectly dragging the conversation onto your server, and doesn't stop the remote instances users from harassing your users. And so it's often users pushing for harsher blocking.

In any case on Mastodon people have choice - if you don't like your local admins mod decisions, you can move elsewhere and take your followers with you, so if anything mods have far less power on Mastodon than most places.

[ilyt]

> In any case on Mastodon people have choice - if you don't like your local admins mod decisions, you can move elsewhere and take your followers with you, so if anything mods have far less power on Mastodon than most places.

The "I now have to run my own server, and tell my followers to move with me" is kinda the blocker here

>In any case on Mastodon people have choice - if you don't like your local admins mod decisions, you can move elsewhere and take your followers with you, so if anything mods have far less power on Mastodon than most places.

The amount of power they have is same or even bigger, just over smaller amount of users.

[denysvitali]

But that's not the reason you switched from Twitter to Mastodon right? Because as you're describing it, the problems are similar - although on a smaller scale.

The main difference is that with Mastodon it seems like you have a choice to move away from a rogue instance

[tedivm]

> Sure, it is kind of decentralized, but the admins of that 30k instance are effectively able to read the DMs, impersonate users and delete their content.

There's a working group on end to end encryption already and I do believe they will solve that problem.

Archiving content is trivial and can be automated. It's also pretty easy to migrate between instances- I started on one run by a friend but which I felt was too small, moved to one of the biggest ones, and then ended up on hachyderm. I may end up moving again as I feel like the service is getting rather big- it's one of the largest instances now and there are benefits to being on smaller instances that tend to push people towards them.

[CharlesW]

I think it's neat to start a Twitter competitor and build it in the open, but I don't understand how you're doing to get traction without federation or some kind of undeniable USP. Even Twitter had to "federate" with SMS at first.

Tip: On https://about.opendolphin.social/about, the word "Retribution" is probably not the word you want here. "Compensation", maybe?

[denysvitali]

Thing is... I don't know of any particular killer feature currently. It shouldn't also be up to me to decide tbh, as I would like to shape a product that is build by the users for the users.

Thanks for the tip, I'll update the website [1] soon.

[1]: https://github.com/OpenDolphin/website

[ilyt]

I think just having public key posted in DNS record + the subscribers saving both "human name" and public key would be enough; even if someone takes over a domain every subscriber will get an alert that they key have changed; maybe have backup method of just storing `/.well-known/<social-network>/username with same info for those that don't/can't fuck with DNS.

Building on that the list of address+pubkeys can be put somewhere to search (DHT on server nodes?) so if someone moves shop they can still be found. Then the client could either subscribe directly to who they want (akin to RSS), or get on someone's instance (which would be akin to RSS aggregator) to participate in their community.

[vidarh]

Mastodon uses webfinger for this, which scales much better (though I find it annoying webfinger wasn't specified with a url format that'd make it easy to provide static replies like what you suggested), and supports aliases and redirection.

E.g. if you go here: https://galaxybound.com/.well-known/webfinger?resource=acct:...

You'll get redirected here: https://m.galaxybound.com/.well-known/webfinger?resource=acc...

Which will return a webfinger profile, which includes this activitypub profile (curl command line because you need the "Accept:" header):

curl -H "Accept: application/activity+json" https://m.galaxybound.com/users/vidar

If you look at the "publicKey" key in that JSON doc, you'll see:

{ "id": "https://m.galaxybound.com/users/vidar#main-key", "owner": "https://m.galaxybound.com/users/vidar", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvHAMudraHmCA2u8wcI2/\n7iB0Td73AF7tk3LC7AuUxzCMu0Ipf/mNVdh+2nFOQ0pY+7E/wEgGeFg5BlMNC7hK\nebfYtY5ZFm7upVqQ0OXTP2hC+fnDTNcpmnPqmwMRdL54YtiZvQtRzW++ZKquWjER\nInM97NsjW0H0yuVkMETfPX1ilWkzTlWa9m0+H5Tmaz3EbKk3VanJXSLKNLnSq2lK\nbKcr2kD/U5UobzJDaaKjK+tW50iTOMiFEXLAT+4Po375WlgxKchahvtPyioiDm6j\noneGAbKRM/eAiHf7EhP76zyoL/LNG0XP4rDEFr4Ia4vo4HG1zhbGZ+815Tip4lNW\nYwIDAQAB\n-----END PUBLIC KEY-----\n" }

.. which is used to check the signature of my posts when they federate.

From the profile you also know where to get my posts, and can get them either as JSON or RSS if you want to pull them without actually following me.

If someone "moves show" there'll be an alias in place. E.g:

curl -H "Accept: application/activity+json" https://mastodon.social/users/vidarh | jq .movedTo

gives: "https://m.galaxybound.com/users/vidar"

Now, something like a DHT to replace webfinger so a move can be done without cooperation from the original instance might be interesting, but Mastodon works pretty well here already.

[CharlesW]

Disambiguating DHT in case it's helpful for others, even though I'm still unclear how this would be better than what ActivityPub does now: https://en.wikipedia.org/wiki/Mainline_DHT

[MuteXR]

How would a DHT be any better than AP? It's not even close to doing the same thing, very few people would want something that comes with all the massive disadvantages that a DHT would bring.

[aprdm]

Shopify, Basecamp and github sort of disagree with you.