44 ms·
The problem with Mastodon is that it solves nothing. You are at the mercy of whoever runs the instance you join. What we need is a protocol. Maybe the upcomin
by Timja 4y ago
The problem with Mastodon is that it solves nothing.
You are at the mercy of whoever runs the instance you join.
What we need is a protocol. Maybe the upcoming NOSTR is a good approach:
https://github.com/nostr-protocol/ https://github.com/nostr-protocol/
- schmichael 4y agoActivityPub is the protocol Mastodon implements as stated in the article. You can run your own instance or pay someone to host an instance for you that you otherwise have full control over. You can pick exactly how much or little of your stack you want to own from the code to the followers.
- Timja 4y agoYes, if everybody would run their own instance, that would make it decentralized. But that is not going to happen. We need a protocol that allows ownership of your social graph without having to host your own server.
- deleted 4y ago[deleted]
- schmichael 4y agoYour original post said you wanted a protocol, not a decentralized protocol. Mastodon/ActivityPub have chosen a federated model over a decentralized one. Federated has a lot of usability and scalability benefits over decentralized, but users sacrifice some privacy and ownership abilities. Everyone is free to choose their own tradeoffs.
- jayknight 4y agoI'm interested to see where https://atproto.com/ https://atproto.com/ goes.
- meowface 4y agoThe README for that repo discusses Mastodon/ActivityPub: >The problem with Mastodon and similar programs >User identities are attached to domain names controlled by third-parties; >Server owners can ban you, just like Twitter; >Migration between servers is an afterthought and can only be accomplished if servers cooperate. >It doesn't work in an adversarial environment (all followers are lost); >There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out; >Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody; >It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often;
- elsjaako 4y ago> Then, users are subject to the despotism of a single person Isn't this basically why people are fleeing twitter? >Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody; As an example, the admin of mastodon.technology recently closed the server due to personal reasons. He gave everyone a month to migrate. The process was pretty smooth for me. > It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. Not all data is sent, this is why not every post ends up in the federated timeline.
- gonehome 4y agoI generally agree - without solving the underlying issues you end up back centralized on a handful of providers again (except with a shittier experience) sort of like email. I work on Urbit now[0], but I also think it (or something a lot like it) is the only way out of this that I've seen with a potential path to actually working. Mostly because it tackles the upstream reasons why federated system fail (spam, distinction between account and server, linux being too hard to administer, keeping things on the same version, etc.)[1][2] [0] https://tlon.network/ https://tlon.network/ [1] https://zalberico.com/essay/2022/09/28/tlon-urbit-computing-freedom.html https://zalberico.com/essay/2022/09/28/tlon-urbit-computing-... [2] http://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html http://moronlab.blogspot.com/2010/01/urbit-functional-progra...
- WaitWaitWha 4y agoMandatory xkcd https://xkcd.com/927/ https://xkcd.com/927/
- chromatin 4y agoHappy to see Nostr here. I have been playing with this (you can too by creating a pub/priv keypair at https://astral.ninja https://astral.ninja or https://branle.netlify.app/ https://branle.netlify.app/) and am impressed with the simplicity (but potential) of the protocol