4 ms·

It seemed to me that the OP was making a distinctly different suggestion: the real challenge is offering a better UX. Emerging distributed tech won't fix a UX

by cdata 8y ago

It seemed to me that the OP was making a distinctly different suggestion: the real challenge is offering a better UX. Emerging distributed tech won't fix a UX problem just because it happens to be technologically sophisticated (he calls out TOR, but I think he is making a general comment here). Instead, he asks, why not spend some effort giving older tech like RSS a better UX? I'm inclined to agree, but on the other hand it seems like the marketplace of ideas speaks for itself and we should be keeping our eyes on the future.

Hedja 8y ago
I would argue that Beaker is providing a better UX for the web while solving the centralised nature of it. Its API allows websites to provide interfaces for creating and modifying websites tailored for specific audiences, owned by the user. So you can have your own RSS subscriptions in a Dat, a feed reader in another Dat, click a button on a website to subscribe to it and add it to your Dat. The Feed reader can keep track of what you've read and store it in its own Dat or a different Dat (if you want client/data separation). Your mobile phone can sync to your Dat(s) so you have Desktop/Mobile sync all in a single place. I've not tried this, but I don't see why it wouldn't work.
- kingnight 8y ago
  How does a mobile phone sync dats? The main drawback I see currently with beaker is their is no mobile version (for iPhone)
  - api 8y ago
    Mobile as a whole is an unsolved problem for decentralized systems. The mobile revolution is and has been by far the most powerful driver of centralization in the last 10-15 years. Mobile devices are slower, have less memory, and must consume less power than desktop, laptop, or server devices. To achieve good battery life they really need to be in an almost-off state most of the time. Add to this the fact that cellular data plans limit bandwidth and cellular networks are a lot slower than most land-line networks and you also have to be very efficient with the use of bandwidth. This means that decentralized systems that rely on peer to peer participatory propagation of data or distributed compute just don't work well on mobile. Anything with P2P data propagation will use too much data plan and run the radio too much, shortening battery life, while anything with distributed compute will destroy battery life and turn your phone into a pocket hand warmer. Mobile devices really are thin clients. I call them "dumb terminals for the cloud." Since the cloud is mainframe 2.0, mobile devices are the "glass TTY" (e.g. VT100) 2.0. The best solution is probably not to fight the nature of mobile devices as thin clients but to tether them to stationary devices. But which stationary devices? Laptops are themselves mobile and are off half the time, and most people (myself included) no longer own desktops. I have a personal server but I'm a geek and a huge minority. Most people just do not own an always-on device. Farming this out to random always-on devices is a security nightmare or at best is no better than the vertically integrated silo-ed cloud. I see only three solutions: (1) Create a niche for a personal always-on server type device and successfully market one to the end user. It would have to be open enough to allow the server side of 'apps' to be installed. Many have tried to do this but nothing has caught on. (2) Create a mobile device that's designed to be a "real computer." With 5G coming the bandwidth for this might be on the way, but you'd also have to contend with battery life and heat dissipation. One avenue would be to split the CPU in two: a high-power burstable CPU and a low-power slow always-on CPU. Require the always-on parts of decentralized services to run there and as a result to be very optimized. The problem is that a mass-market mobile device is a huge undertaking. Another route might be to sell a snap-on case that carries an extra battery and also includes a mini-server CPU, RAM, storage, etc. This would make your phone a bit bulkier but if there are benefits / killer apps it could catch on. (3) Solve the security problems inherent in appointing random stationary nodes to serve random mobile devices. This would probably involve a major innovation like fast scalable fully homomorphic encrypted virtual machines or really tough security enclave processors.
    - bubbleRefuge 8y ago
      For the battery problem, what about the proliferation of wireless charging ?
    - noyesno 8y ago
      Mobile devices could certainly be used to host such services /when they are being charged/. In practice most of us charge our devices during the night and, like cheap night-time electricity, we could have overnight mobile seeding. ... and it is always night-time somewhere in the world.
    - staticvar 8y ago
      We would love for someone to test these theories using Bunsen Browser! Getting some solid metrics would go a long way to starting to solve any problems that might be there. Theoretically it shouldn't be eating up much bandwidth because every device visiting a Dat Archive helps contribute to the network.
    - stev0lution 8y ago
      I really enjoy your thinking.. Do you have some kind of blog where I can follow you? :D As you already mentioned, contributing whatever resources you consume is relatively unreasonable on mobile devices, because it would pretty much double data and battery usage. So while there is most likely some kind of overhead connected to the third solution you suggested, I still think it is probably the easiest one because it doesn't require any new specialised hardware. Maybe regulation can solve some of the problems with the current systems, but the idealist in me really wants to see provably transparent (open source) and secure solutions which don't require trust in the hardware so we can still make use of modern, efficient (federated) server farms without having to giving up control over our data.
      - api 8y ago
        My seldom-updated personal site is http://adamierymenko.com/ http://adamierymenko.com/ It's actually worse than doubling. The nature of distributed systems means that participating in resources consumed normally triples resource consumption at least. I'm not aware of any approach to decentralization of services like Facebook, Twitter, etc. that would merely double it. Your typical desktop or laptop has a lot of resources to spare. Your typical mobile device has none. Mobile promotes a client/server mainframe/dumb-term architecture for fundamental technical reasons.
  - staticvar 8y ago
    I've been helping to develop Bunsen browser for Android but we don't have an iPhone build yet. The hard part is just building it with nodejs all wired up correctly for iOS, but there are tools for that. We just don't have the volunteer working on it yet.
stephengillie 8y ago
This is something addressed in a side project I'm building. Websites are converted to JSON (or built as JSON), then built in the browser by a small Javascript engine. Since sites are just JSON, they're highly portable, and sections or whole pages can be simply copied from one file to another, to add content to your site. The project is in late alpha - I'm just now completing the in-browser editor that uploads to S3. Other than requiring fewer server calls, it uses traditional browsers, servers, networks, etc. https://www.sparational.com/ https://www.sparational.com/
fragmede 8y ago
Because there's no money in making a better RSS reader. I'm sure the internal story of why Google killed off Reader is far more mundane office politics that we'll ever know, but since then, there's not been another that's risen to popularity. As the article mentions there's Feedly who's UI is functional if a bit baroque (why does every feed need to be tagged?) but ultimately it's still like trying to drink from a firehose. There's not been an RSS reader company that has come about since that shows Google was wrong to kill off Reader. It's easy enough to think up improvements to their UX, but we don't have a marketplace of ideas because there is so much friction (even ignoring the work involved in starting up a company and hiring a team, there's no way to introduce a small tweak to Feedly without recreating their platform - and then you'd still have to convince enough people to migrate to your Feedly-clone first). What we have a marketplace of VC-funded corporations, and branding is king. There's no stock exchange for listing specific features Feedly could implement in order to promote better RSS reader software.

by cdata 8y ago

Hedja 8y ago

I would argue that Beaker is providing a better UX for the web while solving the centralised nature of it. Its API allows websites to provide interfaces for creating and modifying websites tailored for specific audiences, owned by the user. So you can have your own RSS subscriptions in a Dat, a feed reader in another Dat, click a button on a website to subscribe to it and add it to your Dat. The Feed reader can keep track of what you've read and store it in its own Dat or a different Dat (if you want client/data separation). Your mobile phone can sync to your Dat(s) so you have Desktop/Mobile sync all in a single place. I've not tried this, but I don't see why it wouldn't work.

kingnight 8y ago
How does a mobile phone sync dats? The main drawback I see currently with beaker is their is no mobile version (for iPhone)
- api 8y ago
  Mobile as a whole is an unsolved problem for decentralized systems. The mobile revolution is and has been by far the most powerful driver of centralization in the last 10-15 years. Mobile devices are slower, have less memory, and must consume less power than desktop, laptop, or server devices. To achieve good battery life they really need to be in an almost-off state most of the time. Add to this the fact that cellular data plans limit bandwidth and cellular networks are a lot slower than most land-line networks and you also have to be very efficient with the use of bandwidth. This means that decentralized systems that rely on peer to peer participatory propagation of data or distributed compute just don't work well on mobile. Anything with P2P data propagation will use too much data plan and run the radio too much, shortening battery life, while anything with distributed compute will destroy battery life and turn your phone into a pocket hand warmer. Mobile devices really are thin clients. I call them "dumb terminals for the cloud." Since the cloud is mainframe 2.0, mobile devices are the "glass TTY" (e.g. VT100) 2.0. The best solution is probably not to fight the nature of mobile devices as thin clients but to tether them to stationary devices. But which stationary devices? Laptops are themselves mobile and are off half the time, and most people (myself included) no longer own desktops. I have a personal server but I'm a geek and a huge minority. Most people just do not own an always-on device. Farming this out to random always-on devices is a security nightmare or at best is no better than the vertically integrated silo-ed cloud. I see only three solutions: (1) Create a niche for a personal always-on server type device and successfully market one to the end user. It would have to be open enough to allow the server side of 'apps' to be installed. Many have tried to do this but nothing has caught on. (2) Create a mobile device that's designed to be a "real computer." With 5G coming the bandwidth for this might be on the way, but you'd also have to contend with battery life and heat dissipation. One avenue would be to split the CPU in two: a high-power burstable CPU and a low-power slow always-on CPU. Require the always-on parts of decentralized services to run there and as a result to be very optimized. The problem is that a mass-market mobile device is a huge undertaking. Another route might be to sell a snap-on case that carries an extra battery and also includes a mini-server CPU, RAM, storage, etc. This would make your phone a bit bulkier but if there are benefits / killer apps it could catch on. (3) Solve the security problems inherent in appointing random stationary nodes to serve random mobile devices. This would probably involve a major innovation like fast scalable fully homomorphic encrypted virtual machines or really tough security enclave processors.
  - bubbleRefuge 8y ago
    For the battery problem, what about the proliferation of wireless charging ?
  - noyesno 8y ago
    Mobile devices could certainly be used to host such services /when they are being charged/. In practice most of us charge our devices during the night and, like cheap night-time electricity, we could have overnight mobile seeding. ... and it is always night-time somewhere in the world.
  - staticvar 8y ago
    We would love for someone to test these theories using Bunsen Browser! Getting some solid metrics would go a long way to starting to solve any problems that might be there. Theoretically it shouldn't be eating up much bandwidth because every device visiting a Dat Archive helps contribute to the network.
  - stev0lution 8y ago
    I really enjoy your thinking.. Do you have some kind of blog where I can follow you? :D As you already mentioned, contributing whatever resources you consume is relatively unreasonable on mobile devices, because it would pretty much double data and battery usage. So while there is most likely some kind of overhead connected to the third solution you suggested, I still think it is probably the easiest one because it doesn't require any new specialised hardware. Maybe regulation can solve some of the problems with the current systems, but the idealist in me really wants to see provably transparent (open source) and secure solutions which don't require trust in the hardware so we can still make use of modern, efficient (federated) server farms without having to giving up control over our data.
    - api 8y ago
      My seldom-updated personal site is http://adamierymenko.com/ http://adamierymenko.com/ It's actually worse than doubling. The nature of distributed systems means that participating in resources consumed normally triples resource consumption at least. I'm not aware of any approach to decentralization of services like Facebook, Twitter, etc. that would merely double it. Your typical desktop or laptop has a lot of resources to spare. Your typical mobile device has none. Mobile promotes a client/server mainframe/dumb-term architecture for fundamental technical reasons.
- staticvar 8y ago
  I've been helping to develop Bunsen browser for Android but we don't have an iPhone build yet. The hard part is just building it with nodejs all wired up correctly for iOS, but there are tools for that. We just don't have the volunteer working on it yet.

stephengillie 8y ago

This is something addressed in a side project I'm building. Websites are converted to JSON (or built as JSON), then built in the browser by a small Javascript engine. Since sites are just JSON, they're highly portable, and sections or whole pages can be simply copied from one file to another, to add content to your site. The project is in late alpha - I'm just now completing the in-browser editor that uploads to S3. Other than requiring fewer server calls, it uses traditional browsers, servers, networks, etc. https://www.sparational.com/ https://www.sparational.com/

fragmede 8y ago

Because there's no money in making a better RSS reader. I'm sure the internal story of why Google killed off Reader is far more mundane office politics that we'll ever know, but since then, there's not been another that's risen to popularity. As the article mentions there's Feedly who's UI is functional if a bit baroque (why does every feed need to be tagged?) but ultimately it's still like trying to drink from a firehose. There's not been an RSS reader company that has come about since that shows Google was wrong to kill off Reader. It's easy enough to think up improvements to their UX, but we don't have a marketplace of ideas because there is so much friction (even ignoring the work involved in starting up a company and hiring a team, there's no way to introduce a small tweak to Feedly without recreating their platform - and then you'd still have to convince enough people to migrate to your Feedly-clone first). What we have a marketplace of VC-funded corporations, and branding is king. There's no stock exchange for listing specific features Feedly could implement in order to promote better RSS reader software.