45 ms·
Is there any reading on getting starting with building decentralized apps?
by groffee 4y ago
Is there any reading on getting starting with building decentralized apps?
- throwaway0asd 4y agoDepends on your definition of decentralization. Everybody seems to have either a personal best definition or simply aligns to some trendy product (that likely isn’t at all decentralized). My personal definition of decentralization is peer to peer without a server in the middle, like a telephone call. Nobody seems to like that definition because it’s extremely non-commercial.
- blitzar 4y ago> like a telephone call Which is routed through centralized exchanges ...
- 3np 4y agoRouted through, not terminated at. Important distinction. Modern web is more like everyone calling through a handful of major PBXes.
- blitzar 4y agoIf I pull the cable out of the back of the exchange / pbx what happens? The phone doesnt work.
- throwaway0asd 4y agoA router is not a server.
- stoplying1 4y agoIn the context of censorship-resistant technologies, this is both technologically and semantically incorrect.
- Karrot_Kream 4y agoThat makes no sense. A router is a box with routing rules and a few NICs on it. I have one setup in my house that's routing packets from an overlay LAN onto my home LAN. It is very much a piece of infrastructure that I own, and if I didn't control both ends, I would certainly want to be careful with operating it. If packets were E2E encrypted, I'd still be able to shut off my server and sever the link. If you want true P2P with no intermediaries, then you need a direct P2P technology like a direct Ethernet connection or an L1 radio link with encrypted packets (and even this is fraught with a single RF collision domain.) Otherwise you are also just using a "personal definition of decentralization" that you gatekept about in your comment.
- throwaway0asd 4y agoIntermediaries cannot be avoided. Signals between devices are always open to interception whether that medium in between is copper, air, water, something else. That is completely out of scope. The goal is to prevent deliberate third parties and regard unintended third parties as security consideration.
- throwaway0asd 4y agoThe internet is composed of routers and switches, but those aren’t application servers. Telephones have a start point and an end point without a telephone server in the middle.
- selectnull 4y agoAgreed that everyone has their own personal definition. With that in mind, I would never think of telephone as decentralized, at least not more than any other service provided by a company.
- elitepleb 4y agocrawl from https://gitlab.com/bluesky-community1/decentralized-ecosystem https://gitlab.com/bluesky-community1/decentralized-ecosyste...
- throwaway0asd 4y agoLet's assume you want to build a decentralized application according to my personal definition of decentralization: peer-to-peer with no application servers of any kind. 1. To me this means IP address to IP address communication. But but but IPv4 NAT address: for this there are TURN servers which look pretty expensive. A TURN service provides application layer routing, like a proxy, to route data to a respective node on a private network. 2. I don't want to pay for TURN or deal with the extra layer, so I just write off nodes limited to a NAT IPv4 address on a separate subnet. 3. You need to account for session/relationship management. For this I am using a tiered model whereby nodes are assigned a group identity that allows for increases to access inversely proportional to autonomy. 4. You need some manner of trust validation. This is the piece social media doesn't know how to solve without some sort of centralized ledger. I am just using certificates and putting this liability directly onto the users to properly execute a text challenge response. 5. In a peer-to-peer decentralized model both ends run a listener for incoming connections on a fixed port. That sounds amazingly close to the definition of a server, but each connection is otherwise a client-to-client tunnel with a random client port on both ends. That means one end creates a client connection and points to a remote user running a listener. That listener spawns a connection to a client port and performs the checks to verify connection establishment, validation, anything else. After that initial processing on the listener you are left with a connection. If the connection is bidirectional both ends must listen for incoming data equivalently and must manage sessions and relationships equivalently. Finally, you need to rethink how your prioritize software. Commercially software obtains value from that which you own, which is either a copyright on an application or data in a database. In a decentralized world data is that which you are willing to access or transmit and nothing more. The value is purely functional to your application and nothing for you to secure behind a subscription. That said the value of a decentralized application comes down to three things: * automation - whether the application eliminates manual effort * transmission - whether the application can connect over a network in a way that resembles immediate local device access, such as real time bidirectional communication * utility - does the application do something amazing, which is more than putting data on a screen. You have to think bigger than a webpage or a spreadsheet. Once you solve for transmission and OS challenges end to end encryption is as simple as turning on your application.
- 4y ago