I’ve been using mastodon for a month or two now. I never used twitter but thought I’d try it out for fun since I love this new fediverse experiment.

Then my mastodon instance started experiencing some downtime and I wondered what happens in this scenario. It seems if the goal is to have lots of smaller instances and decentralize social media, then instances, particularly those not run a big companies (who can reliably fund things for years on end and sell ad space on their platforms), will come and go and users will lose their identity or home base each time this happens along with all their followers and their connection to the wider social graph. This seems not great.

It seems that nostr might actually be a fix for this. In nostr:

  • You publish to multiple relays (essentially instances) and anybody from any relay can follow you.
  • Your messages are signed by your key so you can prove they are authentic.
  • If your relay goes down, people can still follow you via other relays
  • You can change between relays without losing your identity. Your post history and followers follow you, not [email protected].

Doing some reading, it seems people’s main criticisms of nostr are:

  • Interface isn’t as pretty. Looks like this has come leaps and bounds in the past six months but of course could always use more work
  • Populated by crypto bros. This seems like not an issue long-term, there’s plenty of crypto bros on mastodon, you can just not follow them if you don’t want to see them. The idea that you can “tip” with a tweet or whatever nostr’s term for that is seems pretty interesting.

Basically, at a protocol level, nostr seems better in some important ways and the cons don’t seem protocol related but userbase and UI related.

What am I missing on the pros/cons list? Anybody got experiences to share?

  • 0xtero
    link
    fedilink
    5
    edit-2
    1 year ago

    you follow nobody

    You can import/export most things to CSV (follows, lists, blocks etc)
    This way it’s easy to set up a new account on new server (as I said, I’ve been instance hopping for a long time).

    You can also download your media archive in its entirety. And you should.

    You should also turn on scheduled deletion of your old posts. You don’t really want to leave >6 month old messages behind you. You don’t have to lose your stuff, just stick the archive somewhere safe (local disk, or dropbox, whatever). These are all standard Mastodon features.

    unless they authenticate you in some other way and that’s a major pain.

    You should always authenticate yourself on Mastodon if you’re “serious” about your identity. It’s very easy to do and re-pointing it to your new “official” identity is just one line of HTML.

    Mastodon has also feature for moving instances and forwarding your old identity to your new one.

    If your instance admin suddenly disappears and shuts down the service, it’s a pain, but obviously you run the same risk with any commercial company shutting down your account without notice or recourse to re-open it. So keeping regular backups of your data is a good idea, the import/export tools are there.

    The only thing that isn’t automatic is followers. And if your followers are a huge concern (for example, part of your livelihood/patronage) you should probably adopt a multi-platform social media strategy anyway. This way you can always reach your followers, no matter what happens to Twitter or Mastodon (or whatever network). You should be on ALL the networks.

    But for most people who are not “content creators” the amount of followers isn’t really very relevant. It doesn’t mean anything. The quality of the discussions is important. And you can participate in discussions without any followers. It’s not like other commercial networks where the algorithm squelches you if you don’t have enough “clout”. You don’t need followers to discuss with people on Mastodon.

    • Feyter
      link
      fedilink
      21 year ago

      Plus: if you are that dependent on you followers maybe it’s a good idea to be self hosted or at least choose a reliable instance.