In January, we kicked off a thorough review of our developer documentation, and you’ll see useful updates over the next few weeks. We’re curious to hear your thoughts: What projects and products do you believe have exemplary documentation and developer support? What would you find most helpful as you dive into creating new services with DSNP? (For example, what more might we provide with Testnet?) As always, we invite you to add your comments and questions to the discussions at forums.projectliberty.io - and thanks!
January DSNP update - Summary of progress
The chain selection process continues. We are exploring concepts and content mapping onto blockchain, including:
Economic modeling
Benchmarking
Exploring governance questions and discussing how to address the ethical concerns we encounter as we try to create a socially aware web. For example, although we aim to foster a decentralized service ecosystem, there are areas where the market might tend towards centralization. Where is this most likely to happen, how might we evaluate if this centralization is problematic, and how might we respond?
Hi Denise/Team,
It’s probably worth qualifying WHAT, precisely, is being decentralised and why it is important? And, when some centralisation is not necessarily problematic?
Very often, media portrays an over-simplified, polarisation of centralisation (current Web 2.0 ) versus decentralisation (Web 3.0 ) when the reality is more nuanced in that current centralised, managed service provider(s) – MSP(s) – can operate services on behalf of the decentralised Project Liberty. The ambiguous, umbrella-term "decentralisation” is unclear and means many different things. So maybe it is helpful to clarify/qualify what decentralisation means in the Project Liberty context.
Project Liberty decentralisation is really about personal control over our personal data that remains exclusively with individuals – data owners/controllers – but not under the control of an MSP operational service (centralised), concerned with system/data availability only. It is also not likely that individuals’ would want to run-up their own decentralised servers rather than consume from a centralised, MSP offering and this is not really problematic. Centralisation at a service operational level has advantages but individuals’ will remain data controllers.
The real value of Project Liberty’s is the emphasis on data-decentralisation, in particular. As we all know, currently data is centralised ( Web 2.0 ); harvested, aggregated and profiled by centralised, surveillance algorithms that are not transparent. These centralised nudging algorithms capture the attention economy to serve-up advertising that serves shareholders. Individual users are not stakeholders. It is this rich data-centralisation that feeds the algorithms ( Web 2.0 ).
In contrast, Project Liberty’s decentralisation – is data-decentralisation – transfers control over personal data and it’s use to serve the individual, who is a stakeholder. This does not preclude utilising appropriate, centralised operational services.
Something along these lines seems a perfectly reasonable Project Liberty response on qualifying decentralisation? Just thoughts on helping frame a response.
I think you are correct that decentralization is a term that has been thrown around a lot without much meaning. There are also many degrees of decentralization as you mentioned. I also agree that if we want to reach the vast majority of users, it is (currently) unlikely to succeed to require users to run anything more than a client.
Even within data-decentralization there are other levels of decentralization. For example there is small, but important difference between content decentralization and decentralized proof of existence of content. There is also decentralized accessibility of content (in likely at least two forms!).
So to answer your question, I think DSNP in particular falls into a few sub-categories of decentralization:
Decentralized Sender Proof: DSNP tries to ensure that if you know of a piece of content, then you should be able to prove the user that it claims to be from is indeed the user (or a delegate of that user) sent it. (Signatures | Liberty Protocol Spec)
Decentralized Provider Association: Users should be able to move from one provider to another or use multiple providers without loss of Identifier or Graph. (Overview | Liberty Protocol Spec)
While the DSNP spec does not currently deal with private messages, the whitepaper does some and we have been researching ways to make this work in a multi-client “Decentralized Provider Association” system.
The other piece that DSNP is not prescriptive on is content storage. While services might arise that use decentralized providers, I don’t know if DSNP should speak to it outside of having a supported list for cross application support.
Hi @wil,
Thank you for the helpful decomposition on “sub-categories of decentralization” which seems to indicate that an IdP (Identity Provider) rather than DSNP assumes responsibility for establishing a verified ID and producing an associated digital signature that the DSNP can utilise. Is that your thinking? Am I right on this?
As an aside but relevant, our current world of centralisation is facing significant regulatory impact based on this latest preliminary decision. If EU-US data flow suspension is upheld or even a mandate is made to change current data harvesting practices, then I think it is a Project Liberty approach that will set the new direction on data-decentralisation:
It depends. What I was trying to say is that DSNP cares about a pseudonymous identifier and the system to prove control of that identifier. (In the case of Ethereum, via the publishing of the keys and delegated keys associated with it.) What DSNP does /not/ try to do is any form of “real world” identity. Due to the overloaded nature of the word “Identity” I have started falling back to the word “Identifier”. It might just be more confusing however. Identity to me still evokes that mental image of a driver’s license or passport.
Now of course some users may choose to reveal or prove their “real world” identity and I can imagine developers integrating one or more forms of Twitter’s “verified blue checkmark”. However that would be built on top of DSNP.
Hopefully that helps. We are currently working on splitting the DSNP spec to be more clear about implementation vs implementation agnostic portions. I think I might try to clarify some of these points in the spec.
Hi wil,
Yes, that does help; I think you are correct about a pseudonymous identifier on DSNP rather than “real world” identity and should “real world” identity emerge as a requirement then it can be built on DSNP. “Identity” is as you say, an overloaded term. I’ve found your explanations helpful so reflecting them in the spec. will benefit others too, I’m sure.
Kind Regards,
Patrick