5 ms·

I think there are 2 issues at play here. The first one, the article touched on obliquely: > Back in those days of high adventure hosts were far more than mere

I think there are 2 issues at play here. The first one, the article touched on obliquely: > Back in those days of high adventure hosts were far more than mere pets, they were golden temples where crusaders came to worship speaking prayers of code. > > Today, servers aren't even cattle, servers are insects connected over fast networks. Centralization is not only possible now, it's economical, it's practical, ... "Back in those days" users were administrators of one sort or another because that was the barrier to entry. But administrating systems sucks, even if it's just a PC. The rise of server-less is just another testament to this: being able to outsource the boring, tricky bits to experts is great as long as the principle-agent problem doesn't rear its head too often. The second issue is that distributed (I suppose some people might call them federated) identity systems don't work very well. Look at the vast gulf between the spam problem on Facebook and the spam problem with email. If you've signed up with a centralized identity system, it's pretty convenient to use a bunch of services synced up with that identity: all of the social media stuff is probably the tip of the iceberg.

api 8y ago
This is a huge barrier to today's decentralized systems. I wanted to check out Mastodon and looked into setting up a node. It's a nightmare of rube goldberg machine dependency hell. It's not that I can't, but that I don't have time to mess with it. If decentralized system designers want these things to take off they must get better at writing clean code with a good UX. Start with a good UX for admins: single install, dependent on not much more than maybe a database or language runtime, easy upgrades, and good docs about how to get started. Then as the product matures work up to UX for end users. You will never get to the latter if you don't plan ahead a little and avoid design and runtime choices that drag in heaps of complexity or limit portability. Decentralized protocols are maturing, but UX is still awful. I think UX is half the problem. The other half the problem is defending against attacks. In today's world where computer networks and even simple services on them like discussion platforms can be targets for professional criminals and even national intelligence agencies, anything that gets popular will get seriously attacked. Centralized systems are far more straightforward to defend: block IPs, kick off users, update software in one place, etc. People like to hold up cryptocurrency as one system that has withstood constant attack, but that is only true if you limit scope to the protocol. As a holistic system cryptocurrency has been and continues to be successfully attacked with social engineering. Scammers are siphoning billions out of the cryptocurrency economy. On centralized economic systems like banks and exchanges you can ban, freeze funds, delist, and regulate.
- teleclimber 8y ago
  > I wanted to check out Mastodon and looked into setting up a node. It's a nightmare of rube goldberg machine dependency hell. It's not that I can't, but that I don't have time to mess with it. I've come to the conclusion lately that the thing holding decentralization back the most is that sunning any kind of server-side code is challenging to set up and a regular pain in the neck to maintain. This prevents even tech-savvy people from setting up their own nodes of whatever cool tech happens to come out (not just social networks, but RSS readers, bookmarking apps, you name it: there is an OSS thing out there that fits your needs but is a PIA to install and run.) And in turn this limits the number of nodes that will ever run on a decentralized service, and nodes will constantly go offline as admins get fed up with running them. We need the ability to install and run server software as easily (almost) as we can install something on our phones. Maybe a layer on top of Ubuntu Server, with a baked in web UI so that any Joe can get a DO droplet and start serving.
  - api 8y ago
    Go has the right idea: big static binary. This will remain the best answer until dependency and package management systems advance beyond the 90s.
  - 18pfsmt 8y ago
    Much like many projects on github have a "deploy to heroku" perhaps Linode or DO could make deploying a Mastodon instance as simple. There would need to be a good admin panel UI, as you said (manage federation links, users, blacklists/whitelists). It could even be free for the 1st month. If there is demand, my guess is these services will emerge.
  - gbhn 8y ago
    You'd appreciate sandstorm.io
    - teleclimber 8y ago
      I was a backer when it came out but it has not become what I had hoped it would be. It seems the need to alter the applications to work as a sandstorm app means most apps were a few versions behind and often contained bugs. I tried doing some of the simplest things and got major fails, so I let it go. Plus it didn't handle the web-centric use case well (only static content [0]), which makes its usefulness very limited as a server-side platform. https://docs.sandstorm.io/en/latest/developing/web-publishing/ https://docs.sandstorm.io/en/latest/developing/web-publishin...

api 8y ago

This is a huge barrier to today's decentralized systems. I wanted to check out Mastodon and looked into setting up a node. It's a nightmare of rube goldberg machine dependency hell. It's not that I can't, but that I don't have time to mess with it. If decentralized system designers want these things to take off they must get better at writing clean code with a good UX. Start with a good UX for admins: single install, dependent on not much more than maybe a database or language runtime, easy upgrades, and good docs about how to get started. Then as the product matures work up to UX for end users. You will never get to the latter if you don't plan ahead a little and avoid design and runtime choices that drag in heaps of complexity or limit portability. Decentralized protocols are maturing, but UX is still awful. I think UX is half the problem. The other half the problem is defending against attacks. In today's world where computer networks and even simple services on them like discussion platforms can be targets for professional criminals and even national intelligence agencies, anything that gets popular will get seriously attacked. Centralized systems are far more straightforward to defend: block IPs, kick off users, update software in one place, etc. People like to hold up cryptocurrency as one system that has withstood constant attack, but that is only true if you limit scope to the protocol. As a holistic system cryptocurrency has been and continues to be successfully attacked with social engineering. Scammers are siphoning billions out of the cryptocurrency economy. On centralized economic systems like banks and exchanges you can ban, freeze funds, delist, and regulate.

teleclimber 8y ago
> I wanted to check out Mastodon and looked into setting up a node. It's a nightmare of rube goldberg machine dependency hell. It's not that I can't, but that I don't have time to mess with it. I've come to the conclusion lately that the thing holding decentralization back the most is that sunning any kind of server-side code is challenging to set up and a regular pain in the neck to maintain. This prevents even tech-savvy people from setting up their own nodes of whatever cool tech happens to come out (not just social networks, but RSS readers, bookmarking apps, you name it: there is an OSS thing out there that fits your needs but is a PIA to install and run.) And in turn this limits the number of nodes that will ever run on a decentralized service, and nodes will constantly go offline as admins get fed up with running them. We need the ability to install and run server software as easily (almost) as we can install something on our phones. Maybe a layer on top of Ubuntu Server, with a baked in web UI so that any Joe can get a DO droplet and start serving.
- api 8y ago
  Go has the right idea: big static binary. This will remain the best answer until dependency and package management systems advance beyond the 90s.
- 18pfsmt 8y ago
  Much like many projects on github have a "deploy to heroku" perhaps Linode or DO could make deploying a Mastodon instance as simple. There would need to be a good admin panel UI, as you said (manage federation links, users, blacklists/whitelists). It could even be free for the 1st month. If there is demand, my guess is these services will emerge.
- gbhn 8y ago
  You'd appreciate sandstorm.io
  - teleclimber 8y ago
    I was a backer when it came out but it has not become what I had hoped it would be. It seems the need to alter the applications to work as a sandstorm app means most apps were a few versions behind and often contained bugs. I tried doing some of the simplest things and got major fails, so I let it go. Plus it didn't handle the web-centric use case well (only static content [0]), which makes its usefulness very limited as a server-side platform. https://docs.sandstorm.io/en/latest/developing/web-publishing/ https://docs.sandstorm.io/en/latest/developing/web-publishin...