3 ms·

The joke of it is that Web3 claims to be the answer to decentralization... but in every case of Web3 there is some reliance upon a block chain. If the block ch

The joke of it is that Web3 claims to be the answer to decentralization... but in every case of Web3 there is some reliance upon a block chain. If the block chain is limited to only the client and not on any server, therefore unnecessary and worthless, it would then be not centralized. I get the impression nobody takes the time to actually parse the word decentralization. It only means not centralized, but that applies to absolutely everything in the scheme. Somehow people get this confused and for whatever reason believe if anything is not fully centralized then all of it must be fully decentralized. In order to achieve actual decentralization with online or web technologies consider this incomplete checklist: * No DNS * No identity manager * No shared server. A server is fine so long as you are the only client that can access it as a server or other clients are currently known and prior authenticated (a peer). * No root certificate or certificate authority or CRL. * No blockchain * No shared database or other shared services Otherwise claims of decentralization are probably just scams to pilfer your data, steal your money, or mine crypto remotely using your hardware. Decentralization is still possible as I have proven it in a personal application of mine, but its very complicated and extremely different from how the web works.

arilotter 3y ago
> * No DNS DHT with either bootstrapping or literally just rip through every single IPv4 addr and see if it's a peer lol. > * No identity manager How do you know what your friends' phone numbers or emails are? Ask them. No centralized DB needed. > * No shared server. A server is fine so long as you are the only client that can access it as a server or other clients are currently known and prior authenticated (a peer). Ethereum (and many of its sibling/child evm chains) clients can run on a Raspberry Pi. It's really not that hard to run a node, and could be packaged into common usage easily. > * No root certificate or certificate authority or CRL. Yeah, this is the big one for sure that needs to be solved :) > * No blockchain What is wrong with a public distributed ledger? > * No shared database or other shared services Not sure what this applies to.
- austin-cheney 3y ago
  > What is wrong with a public distributed ledger? It is a highly centralized artifact, which is maximally self-defeating if the goal is not centralizing. When you actually achieve decentralization nobody else is storing or accessing your activity or hoarding your data. There are no public ledgers or anything to crawl or anything to screen scrape, because its on your hardware and you determine who can access it.
  - ntfAX 3y ago
    [dead]
  - noman-land 3y ago
    Vitalik touched on this topic some years ago. "Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)" https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 https://medium.com/@VitalikButerin/the-meaning-of-decentrali...
- kennu 3y ago
  > It's really not that hard to run a node, and could be packaged into common usage easily. In my experience, it's not hard to run a node, but it can be hard to get it to sync with the Ethereum network, especially using older hardware. You need a lot of fast SSD disk space, and the blockchain keeps growing. Also, nowadays you probably also want Polygon and maybe some other L2 nodes, since Ethereum's scaling strategy is based on layer 2 networks. And they need even more disk space..
anacrolix 3y ago
I have a solution to this in https://github.com/anacrolix/btlink https://github.com/anacrolix/btlink. Addressing your specific points: > * No DNS It extends DNS by mapping naming over DHT, and content addressed data to a corner of the existing DNS system (.btlink is the working example given). > * No identity manager Yep > * No shared server. A server is fine so long as you are the only client that can access it as a server or other clients are currently known and prior authenticated (a peer). It allows for a level of shared server to suit the user, to ease use. You can run your own "server" (the eventual default), or use a public or shared one to get started. Server here refers to a process that extends DNS and serves resources without having to modify existing software. > * No root certificate or certificate authority or CRL. It makes no attempt to modify the existing system in use on the internet. A certificate is required to serve .btlink traffic over https. > * No blockchain Yep > * No shared database or other shared services Yep (I assume a DHT doesn't count here).
- austin-cheney 3y ago
  My goal is to accomplish Zero Trust Conformance[1]. You cannot do that using web technologies in their current form unless you internalize the centralized aspects of those technologies or validate them under contract. [1] https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview https://learn.microsoft.com/en-us/security/zero-trust/zero-t... That is the Microsoft definition. The US Army is forming its own definition because aside from reliance upon cloud vendors as service providers the military owns its own infrastructure and services (OSI layers 1-7). Nobody else can claim that, so the US Army can take Zero Trust to a different level than others are afforded. My goal is to conform to the more demanding military definition for OSI layers 5, 6, and 7. The business case is two-fold: privacy as a mandate and mitigating disruption via logic redundancy. I have an application that is 98% of the way there. I only accomplished this by either internalizing some technologies and abandoning those I could not. As for certificates that is something you can internalize. You can create your own self-signed certificate and corresponding certificate chain necessary to make your OS and browser happy. If you don't need certificates for their actual purpose, trust authority, then all you need them for is facilitating TLS traffic. I am exchanging trust for authentication via identity and key exchange.
kaycey2022 3y ago
* No bits * No wires * Direct brain synchronisation only

arilotter 3y ago

> * No DNS DHT with either bootstrapping or literally just rip through every single IPv4 addr and see if it's a peer lol. > * No identity manager How do you know what your friends' phone numbers or emails are? Ask them. No centralized DB needed. > * No shared server. A server is fine so long as you are the only client that can access it as a server or other clients are currently known and prior authenticated (a peer). Ethereum (and many of its sibling/child evm chains) clients can run on a Raspberry Pi. It's really not that hard to run a node, and could be packaged into common usage easily. > * No root certificate or certificate authority or CRL. Yeah, this is the big one for sure that needs to be solved :) > * No blockchain What is wrong with a public distributed ledger? > * No shared database or other shared services Not sure what this applies to.

austin-cheney 3y ago
> What is wrong with a public distributed ledger? It is a highly centralized artifact, which is maximally self-defeating if the goal is not centralizing. When you actually achieve decentralization nobody else is storing or accessing your activity or hoarding your data. There are no public ledgers or anything to crawl or anything to screen scrape, because its on your hardware and you determine who can access it.
- ntfAX 3y ago
  [dead]
- noman-land 3y ago
  Vitalik touched on this topic some years ago. "Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)" https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 https://medium.com/@VitalikButerin/the-meaning-of-decentrali...
kennu 3y ago
> It's really not that hard to run a node, and could be packaged into common usage easily. In my experience, it's not hard to run a node, but it can be hard to get it to sync with the Ethereum network, especially using older hardware. You need a lot of fast SSD disk space, and the blockchain keeps growing. Also, nowadays you probably also want Polygon and maybe some other L2 nodes, since Ethereum's scaling strategy is based on layer 2 networks. And they need even more disk space..

anacrolix 3y ago

I have a solution to this in https://github.com/anacrolix/btlink https://github.com/anacrolix/btlink. Addressing your specific points: > * No DNS It extends DNS by mapping naming over DHT, and content addressed data to a corner of the existing DNS system (.btlink is the working example given). > * No identity manager Yep > * No shared server. A server is fine so long as you are the only client that can access it as a server or other clients are currently known and prior authenticated (a peer). It allows for a level of shared server to suit the user, to ease use. You can run your own "server" (the eventual default), or use a public or shared one to get started. Server here refers to a process that extends DNS and serves resources without having to modify existing software. > * No root certificate or certificate authority or CRL. It makes no attempt to modify the existing system in use on the internet. A certificate is required to serve .btlink traffic over https. > * No blockchain Yep > * No shared database or other shared services Yep (I assume a DHT doesn't count here).

austin-cheney 3y ago
My goal is to accomplish Zero Trust Conformance[1]. You cannot do that using web technologies in their current form unless you internalize the centralized aspects of those technologies or validate them under contract. [1] https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview https://learn.microsoft.com/en-us/security/zero-trust/zero-t... That is the Microsoft definition. The US Army is forming its own definition because aside from reliance upon cloud vendors as service providers the military owns its own infrastructure and services (OSI layers 1-7). Nobody else can claim that, so the US Army can take Zero Trust to a different level than others are afforded. My goal is to conform to the more demanding military definition for OSI layers 5, 6, and 7. The business case is two-fold: privacy as a mandate and mitigating disruption via logic redundancy. I have an application that is 98% of the way there. I only accomplished this by either internalizing some technologies and abandoning those I could not. As for certificates that is something you can internalize. You can create your own self-signed certificate and corresponding certificate chain necessary to make your OS and browser happy. If you don't need certificates for their actual purpose, trust authority, then all you need them for is facilitating TLS traffic. I am exchanging trust for authentication via identity and key exchange.

kaycey2022 3y ago

* No bits * No wires * Direct brain synchronisation only