Skip to content

Identity spam: a solution

The initial raised problem is to know if new identities had some "problem to solve" to avoid DDOS attacks by sending and writing to the blockchain new identities that were massively generated.

To this, I answered that identities cannot be written without matching the WoT rules, so it is not that easy. During the time identities are being certified, they are in a sandbox of the nodes.

Yet, it is still possible to spam the sandbox of each node.

So @galuel proposed that:

une possibilité serait que même une demande dans le bac à sable soit à minima validée préalablement par un membre (ce qui ne serait pas équivalent à signer). par le membre dépositaire du noeud en question pour être plus précis.

Which I would traduce by:

nodes could refuse any new identity by default, requiring an initial validation from an existing member to be added to the node (which would be a different thing than certification).

This is a good idea, which made me imagine another:

a given node could even refuse any new identity in its sandbox if it was not signed by an authorized key. By default, the only authorized key is the one of the local node. But the owner of a node can also manually or automatically add other authorized keys.

First scenario: add your node and use it to publish your identity

This is a typical case where you do the most by yourself and don't ask anything to other people than getting certifications for your identity.

1. Install your node

You download Duniter and create your identity in it. This is your node, you control it, you can add your identity in it. No problem.

2. Connect it to the network

This is automated procedure, but just to mention you have to be connected to the network.

3. Ask for certifications

People will be able to find your identity on your personal node. Once they certify it, their node will also add it to their database since the public key of the certification will match the key of the node.

The more certifications you get, the more your identity is spread over the network, the more nodes will accept to write it to the blockchain.

Second scenario: ask someone to authorize your identity on its node

If you for some reason you do not want to add a node, just ask someone which has a node to accept the publication of your identity. Then, any certifier of your identity will find it on the hoster you asked to.

Of course, this method implies to spread people where to find your identity: because when you have your personal node, it spreads a peering information which contains your public key, so asking for certifications by giving your public key is enough to find it on the physical network.

It could be done on a website or any other support, since the certification is a human operation.


Note that this procedure makes an identity be physically located on the network before being globally shared. This is an interesting point: identities emerge from localities, other individuals.

Also note of this is a breaking change, not in the protocol, but in the way clients like Sakia/uCoinApps/Cesium will publish and certify identities.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information