DEV Community: João Augusto Perin

So...What are these Decentralized Identifiers?

João Augusto Perin — Tue, 29 Jul 2025 17:36:23 +0000

Recently, I took notice of a "new" type of identifier that is being more and more used through many systems nowadays, but, although it comes with a lot of design decisions that may sound revolutionary at first, we need to be careful before thinking anything more of it.

Let's take a look, today, at the Decentralized Identifiers.

What are Decentralized Identifiers (DIDs)

Decentralized Identifiers, or DIDs, are a new class of globally unique identifiers that are cryptographically verifiable, self‑sovereign, and resolvable without a central authority. Unlike typical identifiers (email, username, social media handle), which are issued and controlled by a central service provider, DIDs are defined in a way that lets the identity controller fully own and control the identifier.

A DID has a canonical form:

did:<method>:<method‑specific‑id>

For example: did:example:123456789abcdefghi

example is the DID method (implementation rules, e.g. did:ion, did:key, did:sov).
The method‑specific‑id is some unique string or public key fingerprint.
The DID itself can resolve to a DID document—a JSON object that holds public keys, service endpoints, authentication methods, and more.

Because DIDs are not tied to any central registry, the holder can generate new DIDs freely, rotate keys, and choose where the DID document lives (on a DID network, IPFS, HTTPS, etc.).

🧠 How DIDs Work (Step by Step)

Creation
You generate a key pair (e.g. ed25519). That public key fingerprint becomes your method‑specific‑id. You choose a DID method, e.g. did:key, which encodes the public key directly, or did:ion, which anchors state updates on blockchain-like infrastructure.
DID Document
The DID resolves to a DID Document that typically includes:
- public key(s) for authentication or encryption,
- authentication and assertion methods,
- service endpoints (e.g. service: messaging, service: vc-storage).
Resolution & Verification
Clients use a DID resolver for the specific method. They fetch (or verify) the DID document, check cryptographic bindings, and confirm that the public key matches. That guarantees: “this DID corresponds to someone who holds the private key.”
Authentication & Verifiable Credentials
Using DID-based authentication (e.g. using JSON‑LD proof or JWT with DID DID‑Auth), the controller proves ownership by signing a challenge. Receiving systems verify signatures based on the DID document.

For Verifiable Credentials, an issuer signs a credential (e.g. a diploma, attestation) using their DID key. The holder stores the credential and later presents proofs, and verifiers check both signature and revocation status using DID resolution or credential registry.

Key Rotation & DID Updates
Some DID methods (like did:ion, did:sov) support versioned DID documents: you can rotate keys, add or remove public keys. The DID still resolves to the latest document, with history anchored immutably (e.g. on multi-party anchoring networks).
Decentralization & Trust Model
- There's no single root authority leasing identifiers.
- Control comes from cryptographic proofs, not trust in a central issuer.
- The integrity of DID history depends on the method (blockchain‑anchored, distributed ledger, registry, etc.).

🛠️ Use Cases & Practical Examples

1. Authentication without passwords

A user generates did:key on their device. When signing into a service, they sign a challenge using their private key. The service resolves the DID, fetches the public key, verifies the signature—and logs the user in.

No usernames, no passwords, no provider‑centralized identities.

2. Verifiable Credentials ecosystem

Universities, employers, and governments can issue credentials (degree certificates, licenses, KYC attestations) signed with their DIDs. Holders store them in encrypted wallets, share only necessary proofs with third parties (e.g. “I have a degree, not which major”). The verifier resolves issuer DID, verifies signature, optionally checks revocation.

Privacy-preserving, portable, and user‑controlled.

3. Decentralized Web of Trust & social networks

In peer‑to‑peer networks, each node publishes their DID document with service endpoints and verification keys. Peers can exchange signed messages or verify membership without relying on central servers.

4. IoT device identity

IoT devices can hold did:ion‑style identifiers. When a sensor sends data to a network, it signs readings—automated systems verify the sender’s DID, its key authority, and optionally check that it was registered at device minting time.

5. Supply chain provenance

Brands allocate DIDs to shipments or batches. Each actor writes attested events (manufacturing, shipping, storage) tied to those DIDs. Verifiers can query events linked to the item’s DID history, confirming origin and transit chain.

⚙️ Implementation Patterns & Tech Stack

DID methods
- did:key: simplest, public key encoded as DID, no blockchain or registry.
- did:ion (built on Sidetree): supports updates, anchored on public ledger.
- did:sov: part of Hyperledger Indy, often used in enterprise credential networks.
DID Document structure
Standard JSON‑LD structure with keys, authentication, service endpoints.

Resolution may return historical versions or meta‑information depending on the method.
Libraries & tooling
Tools like did‑kit, indy‑sdk, veramo, trinsic, or ssi‑web implement DID management, issuance, storage, resolution, and credential flows in languages like TypeScript, Rust, and Go.
Security & key management
Local key stores, hardware security modules (HSMs), or secure enclaves hold private keys. Seed phrases or recovery methods are critical for user control.
Interoperability considerations
Credential formats (W3C VC), proof standards (JSON‑LD, BBS+, JWT), DID resolver compatibility—all matter for systems that interact across networks.

🧾 Pros and Cons

Pros

Self‑sovereign identity: users own their identifiers and data.
Interoperable standard: W3C‑recognized, cross‑platform.
Verifiable and portable: cryptographic assurance without central providers.
Privacy‑preserving: selective disclosure, zero‑knowledge proof support.

Cons

Method fragmentation: many DID methods exist, and not all are interoperable.
Infrastructure complexity: resolution, key rotation, revocation require external networks or registries.
Usability challenges: key management, recovery, wallet compatibility—not as seamless as centralized login flows.
Trust bootstrapping: verifying issuer trust (e.g. a university DID) may still rely on registries or off‑chain trust lists.

💻 Pseudo-code

Here we'll have some basic examples of usage, and some diagrams to help understand the usage of these DIDs:

DID Authentication Flow

// Verifier generates a random challenge
const challenge = generateRandomString();
sendToClient(challenge);

// Client signs the challenge with their private key
const signature = sign(challenge, privateKey);

// Verifier resolves the DID document
const didDocument = resolveDID(clientDID);
const publicKey = extractPublicKey(didDocument);

// Verifier checks the signature
const isValid = verifySignature(challenge, signature, publicKey);

if isValid grantAccess();

Creating a DID Key

// Generate a keypair
const keypair = generateKeyPair(algorithm = "ed25519")

// Encode public key in multibase + multicodec format
const encodedKey = encodeMultibase(keypair.publicKey)

// Construct the DID
const did = "did:key:" + encodedKey

// Create a DID document
const didDocument = {
  "@context": "https://www.w3.org/ns/did/v1",
  "id": did,
  "publicKey": [{
    "id": did + "#key-1",
    "type": "Ed25519VerificationKey2018",
    "controller": did,
    "publicKeyMultibase": encodedKey
  }],
  "authentication": [did + "#key-1"]
}

Resolving a DID

// Generic DID resolver
function resolveDID(did) {
    const method = extractMethodFrom(did) // e.g. "key", "ion", "web"
    const resolver = getResolverForMethod(method)
    return resolver.resolve(did)
}

Verifiable Credential Issuance & Verification

// Verifier checks integrity and authenticity of a credential
const credential = receiveCredential();

// 1. Resolve issuer DID to get public key
const issuerDID = credential["issuer"];
const issuerDoc = resolveDID(issuerDID);
const issuerKey = extractPublicKey(issuerDoc);

// 2. Verify the signature
const isValid = verifySignature(credential, credential["proof"], issuerKey);

if isValid acceptCredential();
else rejectCredential();

🧠 Tips for Real Implementations

Use Well-known libraries like didkit, veramo, or @identity.com/credentials for implementation.
Prefer did:key for ephemeral, short-lived identities.
Use did:ion or did:web for long-lived, public identities.
Use credential formats like JSON-LD for maximum interoperability.
Consider key rotation and revocation strategies early.

✅ Takeaways

DIDs are a thoughtful re‑imagining of digital identity—rooted in cryptographic verification and user control, decoupled from centralized authorities. They enable flows like password‑less authentication, verifiable credentials, and IoT provenance that are portable and privacy‑aware.

Yet, despite their potential, real‑world adoption still faces friction: fragmentation of methods, key recovery UX, and ecosystem trust models. As with variance and authentication systems you've written about, it's essential to look under the hood—understand cryptographic anchors, resolution design, and architectural trade‑offs—before embracing the hype.

What are Blockchain Oracles?

João Augusto Perin — Tue, 29 Jul 2025 17:11:16 +0000

At the core of blockchains lies deterministic, self‑contained code execution: smart contracts run on consensus nodes using on‑chain data only. But most real‑world logic depends on external events—asset prices, weather data, identity verification—and blockchains don’t inherently have access to that. That is where oracles come in. They serve as gateways between off‑chain data and on‑chain logic.

🧠 What an Oracle is

In short, the bridge between on‑chain trust and off‑chain reality.

A blockchain oracle is a trusted data provider that fetches real-world data, submits it to the blockchain, and ensures that smart contracts can verify and act upon that information. It’s not just a price feed—it can encapsulate:

Data retrieval: reading external APIs like market data, weather, flight logs, and IoT sensors.

Data validation and aggregation: from multiple sources to reduce error or manipulation.

On‑chain reporting: pushing that data into smart contracts in a verifiable fashion.

Custom triggers: e.g., “if event X happens off‑chain, execute that function on‑chain.”

Without oracles, contracts cannot reason about events outside their cryptographically sealed context.

🔄 How blockchain oracles work (architecturally)

Smart contract requests
A contract emits a request (e.g., “Request price of ETH/USD at block N”), often via an on‑chain transaction.
Oracle node fetches off‑chain data
The oracle listens for request events, then queries external data sources (APIs, web scraping, IoT streams, etc.).
Data aggregation and transformation
The oracle may fetch multiple sources, compute a median or weighted average, attach timestamps, and check signatures.
Submission on‑chain
The oracle submits the cleaned data back as a transaction, calling a callback or fulfillment function in the contract.
Verification by contract
The contract checks the oracle’s submission (e.g., are signatures valid? Did the timestamp fit expectations?), then uses the data to execute logic (e.g., release funds, trigger bets, adjust collateral).

Optional reputation or staking layer
Many oracle networks incorporate staking or slashing: nodes stake tokens and can be penalized for sending bad data, promoting honesty.

🧱 Types of Oracles

Centralized Oracles
A single data provider (e.g., using one API) pushing data to a contract. Simple, but introduces single‑point‑of‑failure and trust risks.
Decentralized Oracle Networks (DONs)
Protocols like Chainlink, Band Protocol, and Pyth Network — each uses multiple independent nodes, aggregates data, and makes the result tamper‑resistant.
Inbound vs Outbound Oracles
- Inbound: off‑chain → on‑chain (e.g., price feeds).
- Outbound: smart contracts → off‑chain, for event notifications or triggering workflows (e.g, Chainlink Keepers).
Hardware-backed oracles (trusted execution environments)

Fetching real-world data with confidential computing (e.g., Intel SGX attested relays) when data privacy or tamper-resistance matters.

🛠️ Use cases: practical examples

1. DeFi price feeds

Automated market maker perks, lending protocols, oracles supply ETH/USD, BTC/USD, stablecoin peg data to calculate collateral ratios or trigger liquidations. Aggregated feeds from multiple oracles ensure reliability.

2. Prediction markets & contingency payouts

Protocols like Augur or UMA rely on oracles to confirm off‑chain events (election results, sports scores, weather thresholds) to settle contracts and payouts.

3. Insurance and parametric products

Weather oracles feed rainfall or temperature data into smart contracts. If certain thresholds are met (e.g., drought, storm), the contract automatically pays claims.

4. Dynamic gaming & NFTs

Games that depend on outside events—say, token rewards tied to real‑world sports outcomes, or generative NFTs that evolve based on time-of-day or temperature—can use oracles to retrieve that external data.

5. Hybrid smart contracts

Oracles connect on‑chain contracts with off‑chain business logic. For example, a supply‑chain platform might let a contract request shipping data from an external logistics system, with the oracle retrieving and reporting it on‑chain.

⚙️ Implementation insight (tech stack patterns)

Ethereum + Chainlink example
A Solidity contract imports an interface like ChainlinkClient, requests a job that calls an API (e.g. "get": "https://api.exchange/symbol/ETHUSD"), provides a path (e.g. JSON "price"), and gets back the value through fulfill callback.

Chainlink nodes aggregate across multiple APIs, sign the result, and call your contract’s fulfill.
Aggregation logic
Many oracles compute statistics like median, trimmed mean, or weighted average before submission—similar to how a blog post on variance and standard deviation explained computing spread and average: aggregate multiple values, compute mean and variance to identify outliers, then select a robust central value (geeksforgeeks.org, library.soton.ac.uk).
Security considerations
- Use multiple independent data sources to mitigate API outage or manipulation.
- Staking and incentives: Oracle nodes stake crypto and lose it if they submit false data.
- Data freshness and TTLs: contracts should reject stale data.
- Oracle reputation: Many Oracle networks track node performance.

🧾 Pros and Cons

Pros

Enables rich smart‑contract logic tied to real-world events
Automation: no human intervention once set up
Transparency: data provenance can be audited
Decentralization (in network variants) reduces manipulation risk

Cons

Trust assumptions: Relying on off‑chain data introduces risk
Costs: requesting data incurs gas and oracle‑node fees
Latency: off‑chain fetch and on‑chain confirmation take time—less suitable for ultra-low‑latency needs
Complex error handling: stale data, API failures, malicious or misbehaving nodes, all must be handled

✅ Takeaways

Blockchain oracles are the necessary middle layer that let smart contracts interact with the physical world. They translate off-chain realities into on-chain events in a verifiable way. Well-designed oracle networks—using multiple nodes, aggregation, staking, data freshness checks—let decentralized applications be secure, predictable, and powerful.

Docker DNS: The Odyssey

João Augusto Perin — Mon, 27 Sep 2021 14:51:00 +0000

Well, well, well...How could I imagine that configuring a VPN would not be so easy? Hahahaha, ok, I'll explain.

Backstory (feel completely free to skip it right away)

Recently I changed my workstation, I used to code on a Macbook Air before, but now I moved to a desktop, and because of it, I needed to configure my VPN all again, no big deal.

I'm currently using Deepin as my distro, and I did not have much problems until today.

The problem itself

If you have skipped the last part, just to let you know, I need to configure a VPN.

"Ok, but what does this have with docker?" - you may ask.

Well, the VPN setup came up alright, I use OpenVPN and it works just fine.

But the problem came when I tried to access a private address, visible only to the ones with VPN access, and I could not, even though I was connected, but why?

Digging in, I realized that the IP of this specific host resolved on chrome to the page I wanted, so it was a DNS problem.

The .ovpn file

At first, I had a .ovpn file, that looked like this:

client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
proto udp
cipher zzzz
comp-lzo
verb 3
remote xxxx yyyy
#ncp-disable
auth SHA512
#float
remote-cert-tls server
#ns-cert-type server
key-direction 1
<ca>
[..]
</ca>
<tls-auth>
[..]
</tls-auth>
<cert>
[..]
</cert>
<key>
[..]
</key>

And the file above always worked well, I already used this file on Windows, Ubuntu and MacOs, always without any problem.

but this time was different, and after discovering the reason why it was not working (the dns thing), I started searching all over the internet for solutions, even though I have nearly zero knowledge of how things work with docker domain name resolution, but needed it working.

The attempts

I changed my .ovpn multiple times, to different values, parameters, options, and nothing worked. At the point, i was already thinking on changing my distro.

Also, I have to mention that, a friend of mine, a Deepin user as well, told me that he could not use OpenVPN at all on his GUI on Deepin, although by the CLI it always worked fine.

We realize that OpenVPN already ships with a specific script, named "update-resolv-conf", under /etc/openvpn/, but it was not called in my OpenVPN file, and when I did it, it did not work.

Then, the closest I got to actually getting things working, was to redirect the up and down scripts of the .ovpn file to a custom script (provided by the guy on stack-overflow (trustworthy, I know)):

up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved

but, along with it, I had to add some lines above it:

script-security 2
dhcp-option DNS <DNS-IP>
dhcp-option DOMAIN <DNS-DOMAIN-NAME>
dhcp-option DOMAIN-ROUTE .

It had worked, I could access the domain I was trying without using its IP. So NICE!!! that's it?

Oh, no...

So, today I was getting the environment running, and, not to get much deeper here, we had a service which need connection with one of our hosts (and do it by connecting to its domain). But guess what? The docker container was not finding it!

I docker exec -it <CONTAINER-NAME> sh inside it, so I could try with my own hands, and it really does not work.

Searching for what could have happened, I got to the final step:

The resolv.conf file

To be brief, resolv.conf, is a file located in /etc/resolv.conf, which, on official linux man page words:

The file is designed to be human readable and contains a list of
keywords with values that provide various types of resolver
information.

and now, if you already got it, congrats, if not, remember that user-customized script that I mentioned earlier? And the one provided by openvpn?

So, they're both meant to resolve the DNS, but the one provided by openvpn, also, include the new resolved ip's into resolv.conf file, making it visible to the entire system (local, and docker).

So, at last, probably what happened was, chronologically:

.ovpn file did not call the script (in other versions of openvpn it does it automatically).
When I called it by hand, I did not have the dhcp option params on my .ovpn file (again, probably other versions and distributions of OpenVPN do it automatically, but that's not my case, unfortunately).
I added the scripts and the lines with dhcp option definition, and had it working, but only for my machine, not the containers.
When I had the correct update to /etc/resolv.conf file, the containers started seeing the domain.

Conclusion

For the record, my version of OpenVPN was:

OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  1 2020
library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10

But then, as a attempt, I updated my OpenVPN to version 3, it was not that easy, there were some compatibility issues between versions of Debian and Deepin, but I could workaround over it.

When I updated to OpenVPN 3, everything worked just fine, automatically, with the original file, and everything made sense again. It really does everything automatically, and that's why I had never had problems with Windows, or Ubuntu or MacOs, because all of these implementations uses v3 o OpenVPN (Ubuntu not necessarily, but I used in the time).

By the way, if you look into the downloads page, you'll see that the GUI world of OpenVPN (the one used in MacOs and Windows), are called "OpenVPN Connect v3" by the official website, maybe you now know why is it

Unfortunately, my last move was trying to integrate OpenVPN v3 with the Network Manager from Deepin, to use it in the GUI, which would be much more convenient, but I came across this issue, as the comment I highlighted indicates, there is no such integration, at least at the time this post is being made.

Hope you liked, and hope it can help you,
Thanks for reading!

Passwordless: a note on Authentication

João Augusto Perin — Sat, 10 Jul 2021 18:36:21 +0000

Well passwords have been here for a while now, and, as when it was a trend, or the basic go-to option for authentication, it was already questioned about, but not how it is nowadays. Password today can be ~easily~ hacked, or hijacked, or just brute-forced guessed.

As you may think, the main reason why they still here is because they're one of the easiest solutions on authentication of someone or something.

But if you want to be more secure (and more user-frindly, perhaps), passwordless starts coming into play.

Since I started using asciinema, I have been always thinking on how they solved so well the problem on authentication, something like:

Site: "Well, you want to create an account?"
User: "Yes, I do."
Site: "So give me your e-mail, please."
User: "example@email.com, there you go."
Site: "Okay, get your access there."
User: "That's it?"
Site: "Yeah, why not?"

This was sufficient to blow my mind.

'Cause it is REALLY simple, as it could (shouldn't maybe, in some cases) be.

And that's basically it, every time you come back into the site, and put your e-mail on login, the system will recognize that you're already registered, and say again: "Ok, get your access into your e-mail".

Maybe, we should go trough some password issues right now, just so we can get to know some things we're avoiding doing these kind of things:

Users often create weak passwords that are vulnerable to phishing attacks.
Vulnerable to brute-force attacks.
Users often reuse the same authentication credentials on different accounts, leading to Domino-effect.

and that is just three of the first things that comes into mind when we start talking about passwords, I'm not talking about possible issues on the implementations itself, it can occur in cryptography process, or in safe storaging, or any other part of the whole process.

Now, think about just changing the whoooooole work of doing all these steps, into the work of generating a token, and sending it through E-mail, to your user. It can serve as an always-confirm-user-account pass as well!!

I'm not saying passwordless authentication is always based on contacting user by e-mail, it can be made in infinite ways, I have already seen Hardware-related authentication, like really, literally keys, to a system.

I'm just starting the conversation here, what do you think? Did you like the idea? Let me know! 😄

Variance & Standard Deviation 101

João Augusto Perin — Mon, 05 Jul 2021 16:45:32 +0000

Well, Hi there! This is my first Dev.to post, and I'm really excited to begin here! 😁

Perhaps, you already know me from my Tumblr, or my Medium. But nice, and original content will be written here, so take a seat!

To start off, I decided to share a little piece of mathematical knowledge, that, although simple, it is very common to forget, or simply don't come across. But is very useful, and, if you want to follow the path of machine learning, for instance, it is a must know basic concept.

So let's jump in!

O.b.s: I'm assuming you already know the base concepts of statistics. Such as average, mode and median.

Variance

You can think variance, just like the average means like the "center" of the data, variance can mean how the data actually behaves around that "center".

For instance, let's take the mean of these table, which show how many hours of sleep Greg had last week:

Week day	Hours Slept
Monday	7 hours
Tuesday	8 hours
Wednesday	6 hours
Thursday	0 hours
Friday	7 hours
Saturday	7 hours
Sunday	10 hours

This data gives as a average of: 7,6 hours slept per night.

But, let's change the question here, and if we want to know ˜how constant˜ is the sleeping behavior of Greg?

So, now we want to know, having an average behavior of 7,6 hour slept/night, how constant was these hours?

Variance is defined by:

Σ(average - x)² / n 

-> x being the hours slept.
-> n being the amount of data.

So, the example above would evaluate to:

(7-6.42)² + (8-6.42)² + (6-6.42)² + (0-6.42)² + (7-6.42)² + (7-6.42)² + (10-6.42)²

which would result: 10.38

Standard Deviation

Now that you understood variance, the standard deviation, is used to minimize the noise made by the ²'s on variance's formula.

Calculate de SD by: sqrt(variance)

In our case, it will be: 3.22

If you're a little advanced in Maths, you can think of variance as the value of a function y, and the SD being the derivative of the same function. 😉

Foreword

Both have lots of use-cases, that I pretend to bring here on future posts. Hope it helps! 😁