This is part 1 of a series on design decisions I've made in my proposal for how The 1024 Club should work.
It started with an idea tomasino had: give anybody their own 1024 bytes of hosting space, preferrably without input. A few of us fellow tildeverse opers agreed that this would be a cool idea, and so a domain was registered and The 1024 Club was born. That night, I started work on a basic understanding of how this would work.
After a night of discussion, we decided to use public/private key pairs, using a hash of the public key as an address, and requiring that any data pushed to the keypair's kilobyte would need to be signed with the private key, to verify its authenticity.
The first question on the table: what format do we want public keys to be in? There are Python libraries to handle both PEM and the usual OpenSSH authorized_keys format. Both formats have their advantages. Using OpenSSH authorized_keys format pubkeys would allow for easy keypair creation and usage, but using PEM would follow the standards set by most other cryptography users. (ActivityPub, for instance, exposes Actor pubkeys in PEM format.)
Ultimately, I decided on PEM format, mainly because it would be easier for us to use those keys in, for example, verifying the file (no need to finagle the authorized_keys format into a pubkey format OpenSSL can read).
In the next post, I'll talk about the troubles I faced in actually verifying the signature (and trust me, there were plenty of issues).