[Re-listening to the Silmarillion awakens in me the desire to be creative]

Are there many designers here? I'm sure there're some although I haven't found many yet.

Let's use the tag - short and easy - for any user interface concepts of networks?

Since whole interface concepts require a lot of time and energy, I shall post under this tag small features that could be. The ones I'm too shy or too lazy to submit as issues. :)

Please, join
[ and 🥂 ]

Follow

To open closed doors, I shall start with keys.

Some use , some hate it.
Assume that is a LoremIpsum placeholder for any key system.

Many users here cram in fingerprints and post external links. Yet if one uses Fediverse daily, why send me to Keybase, why not encourage me to grab their public key directly from the social profile one uses most often? Uploading it would take a second.

Power networks like Hubzilla allow uploading and exchanging files.

So one can have a dropdown allowing to copy the information, but also a way to download file on click.
Here're profile examples inside the concept I made some time ago.

@lightone Having a convenient way to sign and verify posts with PGP would be so great.

@drq, aren't posts signed already when federated?

@alex they are. But it is a server-side key, which only provides internal authentication.

What I mean is, 'your', client-side PGP key.

@drq, having client-side key would make sense only if all processing was also done on client-side - in the browser. Also clients would have to store locally and maintain public keys of all their contacts as well.

I am not sure if having something like this isn't unnecessary bloat for entertainment-oriented social networks.

@alex yes, the private key should be stored client-side.

Uh... What exactly makes you think of this network being entertainment-oriented?

@drq, general tendencies of use I suppose. Also the model is not very secure where the trust is placed on the server and servers federate with each other on allow-all approach.

Note that I wouldn't mind having this but I am not sure if I would actively use this and how it even should work to be both effective and not pain in the butt.

@alex that's the thing about options: if you don't want, you don't have to.

One of the most frequent criticisms to the Fediverse is that it lacks a proper identity verification process.

Relying on the established PGP process and infrastructure is THE way to solve it without having to resort to central authority, in my opinion.

Well, I wouldn't really mind this, just not sure how it could work without impacting the usability.

@drq @alex I too am a little skeptical this client-side approach is achievable, taking into account the number of implementations and clients provided by the community. 🤔

My idea was much less ambitious - adding the ability to upload public key(s) and conveniently share them (keeping them up to date would be on the user). That way I could grab your pubkey any time (quickly, easily, no need to go anywhere) and perhaps be encouraged to send you a private direct message.

This looks cool!

One of the reasons people post fingerprints instead of full keys is that for non-trivial setups the key would have to be updated frequently. For example each change of expiration, adding or revoking subkeys would need to be propagated to the server manually. Unless they implement some kind of sync or have a keyserver endpoint (this is basic HTTP post) to update the key from the command line.

There is also some overlap with the Web Key Directory protocol that is now ubiquitous among OpenPGP software (e.g. GnuPG and ProtonMail support it). It maps e-mail to keys, e.g. gpg --locate-key torvalds@kernel.org would fetch the key from the following URL: https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x?l=torvalds (WebFinger handles are similar to e-mail addresses).

(More details at https://metacode.biz/openpgp/web-key-directory ).

Oh, btw, I did an alternative to Keybase but decentralized: https://metacode.biz/openpgp/proofs demo: https://metacode.biz/openpgp/key#0x653909A2F0E37C106F5FAF546C8857E0D8E8F074

@wiktor What you're saying is true! Perhaps my layman's assumption that for many users frequent updates won't be needed... is wrong. Then again, people don't always update info on keyservers either. But people seem to take more care in updating their social network's profiles, somehow =) In fact, this very issue of a Fedi user linking to server which did not happen to have their key (was deleted, the user didn't realize it) is the reason why I thought of this interface addition.

@lightone that is a super good idea, I'm not much of a coder but I'd imagine that's very easy to implement for any JS developer as well... this should be suggested to @Mastodon upstream, someone who knows what they're doing could write it and submit a PR.

@aspie4K Thanks! This idea came before Mastodon's main dev announced future plans to add E2EE to direct messages. If/when this happens, this idea will probably be outdated. Although, since some people continue using PGP, I still think it might be useful to have an input in Mastodon specifically for some public key or similar (long) information that doesn't fit nicely into the profile fields.

@alex @aspie4K I don't think so. Normally all the new features go into web version first. In-the-browser then? Not sure. Let's wait and see!

@lightone @alex many platforms perform E2EE within a browser using JavaScript, there may even be open source libraries to implement at this point it's become so common, so this isn't surprising. Very awesome news anyway, certainly much easier than using PGP which is inferior to modern encryption protocols. Element/Matrix has E2EE by default on all platforms using Olm which is similar to Signal and runs in a browser. Guessing Mastodon wants to compete!

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!