💾 Archived View for gemini.panda-roux.dev › log › entry › 18 captured on 2022-04-28 at 17:19:03. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Posted on Saturday July 3, 2021
Yesterday I spent some time implementing a comments feature on my gemlog. It stores user nicknames (called 'aliases') in relation to the client certificate fingerprint that's provided when authoring a comment. These fingerprints (a SHA256 hash of the cert's modulus value) effectively act as unique identifiers representing individual users.
I like this method of personal identification because it can be both unique and consistent across services in Gemini space. Importantly, though, this quality of client certificates is inherently *opt-in* as opposed to conventional web-based fingerprinting. In other words, if I want to be identified across services I can choose to do so; by default, however, I'm anonymous.
In implementing alias lookup via cert fingerprint, I had a thought: what if there was a service I could query and see if the owner of this cert has a profile set up someplace? Instead of storing nicknames in my own database, I could just fetch one that the user's set-up beforehand. The user gets the benefit of having their settings follow them across different capsules, should they choose to assume a given identity.
So it would like kind of like Gravatar or another SSO provider, but keyed on client certificate fingerprints.
I wonder if anyone's done this already, and how much desire there might be for a consentually-centralized service like this.
Flow:
- panda-roux -
next: "Gemlog Comments Feature Changelog"
prev: "New Gemlog Feature - Comments"
[2021-07-03 19:02:44] ~defunct (44d4d):
initially it sounded like a great idea. also you'd be able to update your cert and it retains validity across geminispace. and then there's the issue of some site knowing a ton of data. that site could get greedy. not to mention login times will spike due to the additional request
[2021-07-03 21:11:32] lykso (0bc80):
It should be possible to migrate one's identity to another server and leave a forwarding address behind. It might also be good if the profiles (plus an incrementing nonce to prevent replay attacks) were signed w/ the user's cert, to allow reducing the need to trust the server if the cert's known.
[2021-07-04 00:34:56] panda-roux (d8842):
re: ~defunct the more I think about it the less I like the idea of this sort of centralization, mainly for the reasons you point out. unless this sort of thing could be thoroughly decentralized and/or federated I don't think this will be very positive
[2021-07-04 19:44:08] ~defunct (44d4d):
having had a bit to think about this. how about a data spec and a standardized way to add it to capsules? imagine a capsule that allows you to maintain your data (or local file, whatever). when done you download a sha512 or something, which is a binary format like exif headers that you can upload to
[2021-07-04 19:45:27] ~defunct (44d4d):
capsules to set your data quickly and the capsule can take from it what it needs. with browser support you'd be able to modify permissions for certain capsules, too
[2021-07-05 01:50:11] panda-roux (d8842):
re: lykso I agree that it would be an invaluable feature from a trust standpoint if we could sign users' profile data with their client certs. I wonder if that would have to be implemented on the client-side somehow, though... Something to think about.
[2021-07-05 01:58:51] panda-roux (d8842):
re: ~defunct I'll put some thought into this for sure. Interestingly, I think that idea of passing hashes around is similar to how the bittorrent client identifies blocks of data. With decentralization in mind, there's a certain poetry to that I think.