Comment by samatman | Hacker News Reader

Comment by samatman | Hacker News Reader

My condolences to the admin, this is sad news.

This strengthens my conviction that federation is a bad architecture for something like Mastodon. A fully distributed system, urbit being the easiest to try right now, can't stick someone with the responsibility to keep a bunch of other people online. It can't stick those people with the responsibility to move off the server. Each user runs a server process, locally or on a remote machine. If any of those goes offline, all the services and data it was providing are gone, but no other user accounts are affected.

Federation works fine for Matrix, although I still think the full peer architecture will dominate long-term. It's less disruptive to something like chat to switch user names because a homeserver shuts down.

Mastodon instances get linked into, and all those links are going to break. Running a redirect for those URLs to the numerous new account homes is impractical given that a lack of time and commitment to server maintenance is the issue.

I think you could create a system that's resilient to such issues even with federation (not saying it's easy, though), and Matrix actually has a solution in the works for this – decentralised user accounts [1].

And all of this makes me wonder – maybe it's better to re-implement something like Mastodon on top of Matrix. If Matrix adopts decentralised user accounts, that would seemingly solve such issues automatically. There was a POC Matrix based Twitter clone demonstrating this, actually [2] (but without the decentralised accounts yet).

[1] https://github.com/matrix-org/matrix-spec/issues/246

[2] https://github.com/hackervera/freebird

We’re hoping to make progress on decentralised accounts on Matrix by the end of the year.

https://cerulean.matrix.org is another POC Matrix based Twitter clone (built for Jack & Parag) that demonstrates this (but without decentralised accounts yet).

Doing full P2P just isn't there yet. It makes total sense but without talking about some web3 Blockchain, it's hard to get everyone to run a distributed database, identity server, etc without it being some single binary.

This is where blockchain ends up shining, since there are economic incentives to running a node.

I wonder if for groups up to a certain size, every client could hold all of the data for the group. I think clients do this anyway for caching purposes, but it would mean that as long as any client still had the data, the room wouldn't vanish.

It doesn't scale so well, but if there were an easy ability to (say) plug in an S3 bucket URL for offloading older media, then it might work for quite a while.

An RSS reader does almost everything I'd expect my fully distributed Twitter instance to do. Only thing missing is ability to post, packaged into the same client.

RSS doesn't let people lead discussions through their posts, or did I get something wrong about RSS?

Somehow this usecase completely eluded me when I've sought about how easy it is to setup a way for publishing updates / receiving updates from people you're subscribed to. I can't think of a way for getting content from random commenters in a discussion with a passive RSS-like subscription. At least not without forcing OP to host links to everyone's comments, or involving a third party.

Used to be people would follow blogs through RSS as people made posts, response posts, etc. The quality of discussion was much higher.

Urbit exists right now, anyone with a command line can download it, create a comet, and see what they think.

It can't be denied that it's a practical option, given that there are thousands (maybe in the tens?) of users who are doing stuff on the network.

There's a lot of work which needs to be done, to make the core event loop faster, and enable scaling to the kind of social graph celebrities have. I'm confident in the technical leadership of the project at this point in time.

Full disclosure: I've been a user of urbit for many years, and stand to benefit materially if it becomes popular. I neither work on urbit nor on urbit things, never have, and have invested no money in either urbit or its address space.

I still think it's a good idea, just like I did when it was barely usable and much weirder.

> it's hard to get everyone to run a distributed database, identity server, etc without it being some single binary.

Then it's a real problem that people keep doing these projects in Ruby and PHP. It was a problem that was ultimately laughed off when Diaspora chose it, and it's a problem that continues to linger and continues to be laughed off.

Make it a single-binary that uses a couple sqlite files in a ~/.directory, and people won't mind running their own server. They could opt to proxy their traffic through a caching intermediary, and we could still federate those caching intermediaries. Being a mule for social traffic could be a commodity service if social were standardized properly. Ideally, one would be able to flip a switch and adjust a few dials on one's own instance to become a caching intermediary for others.

This is sort of like the ideal and I think after ruby and php moving on to a new language that can compile down to a self executable makes sense. Whether it's rust or Go to whatever else doesn't matter as much as just taking a new shot at writing something that works.

I half heartedly look at one of my own projects written in Go and wonder if it would fit the criteria but still some work to do. At the end of the day most people don't want to run anything and those that do end up with pages of documentation and maintenance burden.

> Each user runs a server process, locally or on a remote machine.

Mastodon (and similar services) would benefit greatly from (a) requiring users to own their own instances, via commoditized hosting providers, (b) one-click or few-clicks transition between hosting providers, and (c) enabling serverless-style pricing.

Requiring users to own their own instances safeguards users from admin-shutdown.

Ease of migration safeguards users from poor hosting providers.

Serverless-style pricing (e.g. pay per federated message, not by CPU) reduces the financial barrier to entry for new and lite users who are not yet fully committed users.

Reply on news.ycombinator.com