4 ms·
> The only way forward is p2p. Then we as the tech community need to figure out tooling so that grandma and grandpa can use p2p / mesh networks. We have severa
by smush 7y ago
> The only way forward is p2p.
Then we as the tech community need to figure out tooling so that grandma and grandpa can use p2p / mesh networks. We have several challenges in that way that I'd like to see solved, but don't know how to make that happen.
2 immediate challenges is that If you can't get today's iweather over ipfs or bittorrent (with a better UI clearly, not everything has to be file transfer), p2p can't fully replace HTTP. Email is arguably pretty federated if not quite p2p, but the spam problem is real.
The below example is an account of my grandma's attempt to get p2p chat going. Grandma doesn't even know what a p2p / mesh network is, but we will assume she read about it in the paper from the HK protests and being the enterprising unafraid-to-try-new-tech-things user most users aren't, she tries it out.
She is in a large concrete gym, no cell service unless she stepped out of the building for a moment. Remembering the paper article, she decided to try the Bridgefy app so she can text with someone else. How do you spell Bridgefy? Oh right, I have the paper here, let me painstakingly hunt and peck to find the name of the app in the Play Store, ah there it is. She stepped out of the gym, got signal, installed the app on both devices, then stepped back in and opened the app.
Her friend gave her her own phone so she could install both at once so they can be apart, yet chat.
Being forewarned by her techie grandson, she managed a feat denied to nearly all the cell-phone using public and skip the dark patterns of denying Bridgefy contacts, reluctantly giving it location access 'for Bluetooth', and attempting to stop it reading her phone number. Already, 95% of users would be long stopped by now. But she persisted.
The app would not move forward, giving error toast messages of error 7::0 cannot do that. She had to step back outside where she had signal for it to work for an unknown reason.
She got back in the gym, was not able to get either phone to talk to each other, either in 'public broadcast mode' or by trying to add a contact straight from the app. She uninstalled both copies and moved on without having p2p messaging, not because our devices' bluetooth radios couldn't handle ad hoc communication, but because the client doesn't exist that doesn't want to surveil or otherwise profile you.
PS -> that user was not an enterprising Grandma, but myself. If someone knows how to get Bridgefy / a p2p mesh chat app going without selling the privacy farm, I'd love to hear it.
- MiroF 7y agoWas astonished by your grandma's technical proficiency until the end
- u801e 7y ago> Then we as the tech community need to figure out tooling so that grandma and grandpa can use p2p / mesh networks. It seems that the grandma/grandpa use case always comes up in technical discussions. I've never really seen the need to cater to those who aren't willing to learn how to use the tools they have. Could a person born after 2000 figure out how to use a VCR? Set the timer so that it records the correct program? What about a rotary dial phone? Do they know how to make a collect call? What about directory assistance? Could they figure out how to use an 8 track player? They probably wouldn't, but the motivated ones would avail themselves of the resources at hand and figure it out. The same thing applies to current technology.
- shkkmo 7y ago> I've never really seen the need to cater to those who aren't willing to learn how to use the tools they have For tools that depends on network effects to provide value (such as P2P), the on-boarding process and learning curve are quite important to reaching the required levels of adoption. This is especially true when you are competing uphill against alternate tools with established networks that provide more network effect value.
- u801e 7y ago> For tools that depends on network effects to provide value (such as P2P), the on-boarding process and learning curve are quite important to reaching the required levels of adoption. Yet all the examples I gave (rotary dial phones, 8 track players, VCRs) had very high rates of adoption. But I'm sure that there were people from generations once or twice removed from the introduction of such technologies that never really learned how to use them.
- shkkmo 7y ago> rotary dial phones, 8 track players, VCRs None of those products are close to as dependent on network effects to provide value. Rotary telephone didn't depend on other rotary telephone users, just the existence of automatic exchanges. 8 track and VCR didn't depend on other users of the format, but on the availability of content in that format. While they all gain advantages in pricing / availability from networks effects, the core functionality of these products does not depend directly on the network. The rotary dial phone had no real competition. 8 track player adoption was largely driven by large automakers offering 8 track players as factory and dealer installed options (and thus simplifying the on-boarding process). Once 8-track's portable niche was taken over by the easier to use cassette tapes, it declined fairly quickly. VCRs did not face an 'uphill' competition against a competitor with an existing network effect advantage. It can even be argued that Betamax lost (despite having a product that was percieved to be better) because its higher cost relative to VCRs hampered its on-boarding process. There will (almost) always be people willing to cope with a worse on-boarding process and/or steep learning curve. (This is far more true for a product that has functionality not otherwise available.) However, if your product is dependent on network effects and you are competing uphill against a similar product with a well established network, then your on-boarding process and learning curve will be critical (but not the only factor to) your success. It is hard to find a group of products that is more dependent on network effects than P2P software (besides centralized messaging platforms).