Rationale for design decisions?

Is there a place that describes the rationale for various design decisions that have been made, starting with the very basic ones, such as why a new protocol is needed and why a blockchain is required? If so, I can’t find it and would appreciate a pointer.


I think the DSNP whitepaper will address your questions.


It doesn’t. For example, I am looking for a discussion comparing and contrasting with the fediverse, diaspora*, the indieweb, scuttlebutt etc. All of them exist, have largely similar goals, significant user bases and communities … why not build on them? (There may be good reasons; but they need to be articulated.)

1 Like

Hi j12t,

You’re right that we need to do a better job of explaining where we diverge from other efforts. We have taken elements from other projects-- we have definitely built on the work of people who came before. An example of this is our use of ActivityPub schemas as the starting point for how we represent a variety of data in the DSNP protocol. But yeah, more to come as we put some more effort into explaining design decisions for people like you!

Thanks again for asking. It is very useful to have these questions. They help us see where we need to improve the docs.


The white paper briefly mentions: “Federated protocols, with their dependence on shared servers, generally can’t provide strong user data ownership guarantees.”

BTW, I’ve read through the specs and started looking at the code base. A lot of thought went into this and I particularly loved the “Rejected Solutions” section in the Overview section. More of that would be helpful for us newcomers.

In general, open standards and protocols should be incorporated to avoid reinventing the wheel.


“Open standards and protocols should be incorporated to avoid reinventing the wheel”

On that we all agree. Do you see any places where we’ve overlooked an open protocol or open standard we should be using?

Might be good to have this stated as a guiding principle in the specs intro, unless we all believe it’s something that everyone who comes to the project will bring with them as a default principle.

James, in the white paper there’s this statement:

We believe the optimal approach to address these six core aspects is a protocol that leverages an existing public blockchain as a neutral, decentralized platform for data and communications, while defining a standard format for data interaction and employing strong encryption for privacy, allowing any number of different user experiences to be created.

Is there a document that goes into the discussion the core team had regarding utilizing blockchain? What would be most helpful is documenting how the core team intend to address (real or perceived) problems inherent in blockchain technology.

I can certainly understand the advantages to blockchain and I may be stirring up a hornet’s nest since the project is married to blockchain, and that’s certainly not my intent as a non-SME on blockchain technology, but there is some concern over the energy-intensive miners, scalability of the technology (especially if messages are event announcements on the blockchain per the white paper), transaction efficiencies, large size of the blockchain when needing to sync/download it, and the (theoretical) ability to capture a blockchain and corrupt it.

Similar to why certain design ideas where rejected, it would be good to state why these are or are not a concern for the project’s potential future growth. (Maybe this should be a separate thread?)

And thanks to the European Union’s General Data Protection Regulation, anyone living in the EU has the right to request that information about themselves be erased once it is no longer needed. In a blockchain world where blocks are immutable, this might pose a challenge.


Nah, this isn’t a hornet’s nest. It’s a really good question. We’re working on a doc right now to try to get some of those larger design rationales out there. Some of the more detailed design work is in the spec’s github repo, and you can look at commits and issues. That’s pretty granular, though, and doesn’t quite get at the bigger picture questions you’re asking about.

1 Like