Converge is the prototype exchange format for versioned node. It
provides fully featured blobs and versions, including braid
finalization, in encrypted and unencrypted flavors. The encoding with
atlv is compact and simple to parse and build. And the cryptography is
arranged to be compact and efficient.
i’ve been wanting a good way to migrate signature keys in converge.
ideally a migrating key pair that:
- signatures can be verified correct with merely the signing public key
- the migrating secret cannot be derived from the signing secret key
- even if the migrating public key is known
in cryptography, we often require domain separation for different uses of the same primitives.
roughly, this means ensuring that the inputs to a primitive for different purposes cannot overlap.
so there are no instances where you can lift a value from one part of the protocol and use it in another.
i’ve been thinking about data confusion -
interpreting the same pile of bytes as different types.
i quite like the anti-spam property of converge that i described yesterday.
but it also seems a bit too harsh to prevent all automated initiation of contact.
how can we enable some unilateral initiation, as an extra that you specifically need to enable?
the internet has a fundamental assumption that anyone can send anything to anyone.
this assumption has of course been broken at the IP layer by firewalls and NAT,
causing no end of headaches for application developers and users.
that assumption permeates the whole stack -
not only can i send a packet to any computer on the public internet,
i can email anybody, i can message anybody on any of the messaging platforms.
i can tag anybody on social media.
on the internet everybody is next door and can come round whenever they want.
but what if they couldn’t?
i realized that the extra byte of subtag in atlv unions was unnecessary and indeed harmful.
in particular, it has been pushing me to overload tags when using a union would be natural,
because the subtag wouldn’t indicate anything.
i am tired of self-hosting and i’m not alone.
yet i want to have everything still work when the internet is down.
the usual use of the shared secret from a diffie-hellman key exchange is as a symmetric encryption key.
of course, there’s nothing preventing anyone from using it as a secret key for a signing algorithm instead.
it is difficult to focus on income work when outcome work is becoming increasingly relevant to it.
A computer storage paradigm enabling distributed collaboration with disconnected operation.