The library parses rich schemas (nested sections, $ref, arrays, key/value maps, pattern properties…) into a navigable form tree, renders it as a keyboard-first editor, and validates the result after every edit so users always see the full list of issues before saving.

It can be useful someday

A self version of Shazam

hashing: SHA-512
Password or one time code hashing: Argo2id
Key derivation: SHAKE256 or HKDF-SHA512
Api key: prefix + version + Base32LowerCase.encode(UUID || 32-byte secret); hash function: SHAKE256 with a 512 bit output, or SHA3-512 or SHA-512

Encryption: AES-256 has too short nonces, jey / nonce reuse is catastrophic and it's also lacking context commitment. XChaCha20-Poly1305 lacks context commitment, that's why ChaCha20-BLAKE3 is recommended.

Encrypting secrets: use a Key Management Service

Symmetric Key signature: HMAC-SHA512
Asymmetric key signature: ML-DSA-65, or ML-DSA-87
JSON Web TOkens: ML-DSA-65 for asymmetric signatures or HMAC-SHA512 for symmetric signatures

End-to-end encryption

While you probably need more advanced protocols for your specific use case (e.g. The Messaging Layer Security (MLS) Protocol, RFC 9420, for messaging), basic end-to-end encryption to a public key has been standardized in RFC 9180 - Hybrid Public Key Encryption (HPKE). In this context hybrid means that we combine both symmetric and asymmetric cryptography.
Therefore, I recommend the following algorithms for use with HPKE to encrypt data to a public key:

• KEM: X-Wing
• AEAD: AES-256-GCM
• KDF: HKDF-SHA512

TLS

Today, the only quantum-resistant key exchange algorithm available for TLS is the hybrid X25519MLKEM768. Ensure that your load balancers / reverse proxies support it.

# the api key generation
fn hash_api_key(api_key_id: Uuid, version i16, organization_id: Uuid, secret: &[u8]) -> [u8; API_KEY_HASH_SIZE] {
    let mut hasher = sha3::Sha3_512::new();

    hasher.write(api_key_id.as_bytes());
    hasher.write(&version.to_le_bytes());
    hasher.write(organization_id.as_bytes());
    hasher.write(secret);

    return hasher.sum();
}

the storage in the database

CREATE TABLE api_keys (
  id UUID PRIMARY KEY,
  created_at TIMESTAMP WITH TIME ZONE NOT NULL,
  updated_at TIMESTAMP WITH TIME ZONE NOT NULL,

  name TEXT NOT NULL,
  expires_at TIMESTAMP WITH TIME ZONE,
  version SMALLINT NOT NULL,
  secret_hash BYTEA NOT NULL,

  organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE,

  UNIQUE (name, organization_id)
);
CREATE INDEX index_api_keys_on_organization_id_and_expires_at ON api_keys (organization_id, expires_at);

Read from a reddit post

The editor: https://editor.graphite.art/

A non-exhaustive list of Rust usage.

This means that no matter how good (and fast) Clippy is, or how great the memory safety caused by the borrow checker is. The first language that’s taught in many universities is still Java. People use Javascript for everything and C++ is still used in planes. This is why I find it important to highlight and underscore which projects have tried Rust, how the process went and what they learned along the way.

This data structure seems efficient and interesting

Typo-squatting: using URLs is a false solution. "By making crate IDs longer, whether by namespacing within crates.io, GitHub organizations, or via domains, you only make it harder for users to remember them precisely, and thus harder to recognize typo-squatting."

Sandboxing can not be handled by the language itself.

It's the developer responsability to use crates on crates.io. It's an audit to make. Rust provides tool for it: cargo-vet, crates.io 90 day download plot, cargo chef or Nix to build isolation.

Also Rust itself does not have the resources for it at the moment. They simply can't. The compiler and std are primarily developed by volunteers, who don’t get anything out of it except for rare donations from other members of the community. The Rust project is not the same as GitHub or Linux. They don't have the same support.

We’re not nearly close to the level of security a centralized registry can provide. On the software side, in 2025 Rust teams made or piloted tools for typo squatting detection, dynamic build script analysis, and real-time code scanning. On the personal side, Rust Foundation hired on-call engineers in 2025 and a second infrastructure engineer in 2026. If that sounds overdue, well, they had net loss in 2023 – software isn’t cheap.

More efficient but this is typically the tool that should be used when needed :)

A list of available project

and the development is significant

In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

How?

• buy compromised cookies or credentials
• typosquatting or misleading create names
• macros

How to solve?
Again, like Go: having a comprehensive standard library.

It should have: base32, base64, bytes, crc32 and crc64, crypto, gzip, hex, http, json, net, rand, regex, tar, tls, uuid, zip, zstd.

How to fix now?

• Use Dev Containers!
• Password manager for the SSH keys and secrets
• fetch the dependencies from source
• audit the dependencies: cargo-audit and cargo-vet

The post landed today on Lobsters

1. Implement the Copy trait
2. Take parameters by reference
3. Use the proper iterator
4. Have closures capturing by value also return the value

Declare identity to be used by other tools, so the information declaration process can be automated.
A bit sad that AI is the main branding of it.

Export to VCF is added: https://hachyderm.io/@ducks/116324991938693684

The related blog post https://jakegoldsborough.com/blog/2026/whoami-spec-declarative-identity/

They use common logic in Rust. The diagram is definitely interesting.