It kind of makes me think of how odd it would have been if many of the old forums named themselves like bookclub.phpbulletin.com, metalheads.vbulletin.net, or something.

There’s nothing wrong with doing that, obviously, but it’s struck me as another interesting quirk of fediverse instances/sites. Generally as soon as you visit them you can tell by the site interface or an icon somewhere what software they’re using.

  • rglullis@communick.news
    link
    fedilink
    English
    arrow-up
    1
    ·
    11 months ago

    That sounds a lot like an ISP,

    No, that sounds exactly like Nostr, which is a lot more practical and cheap to run that a Mastodon server and actually scales quite well.

    moving all your storage to the edge is usually a bad idea.

    No. You just need to move the application state to the edge. Storage itself can still be in content-addressable data servers, like IPFS, magnet links or plain-old (S)FTP servers.

    When someone posts a picture on Mastodon, the picture itself is not replicated, just a link to it. Now, imagine that your “smart client” version of Mastodon (or Peertube, or Lemmy) wants to post a picture. How would it work?

    • User posts the photo to an IPFS server. It could be a cloud server or it could be their own NAS they have it running at home.
    • The uploaded photo generates a hash.
    • Client takes the hash of the photo and puts in the message.
    • Client signs a message and send to the server
    • Server receives the message, processes it (index metadata, puts the image in its cache to help with seeding, etc)
    • The server has a policy of keeping the image in the cache in the outbox until it has been delivered to at least 70% of the other clients or 5 days, whichever happens first.

    I think that servers are needed.

    If by “servers” you mean “nodes in the network that are more stable and have stronger uptime/performance guarantees”, I agree 100%. If by “servers” you mean “centralized nodes responsible for application logic” then I’d say you can be easily be proven wrong by actual examples of distributed apps.