Follow

[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 πŸ₯‚ ]

Β· Β· 5 Β· 3 Β· 5

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.

Show thread

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.

Show thread

@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!

@π₯𝐨𝐬𝐭𝐒𝐧π₯𝐒𝐠𝐑𝐭 That brings back some memories. We had GPG/PGP support in RedMatrix for a brief period years ago. Some of the code still exists in the Hubzilla and Zap repos - and while it is intentionally incomplete and undocumented (due to legal restrictions in this country), I've at least checked to make sure the interfaces will work with ActivityPub.

@mike Were the private keys saved on the server side in that implementation? For it's unlikely we shall ever see the day when all will have their own hubs. I gave up on the idea of federated networks "private out-of-the-box". Too complex, relying on too many factors (implementations, addons, etc). But if some people still like to use pgp for creating messages (locally) and then exchanging them inside Fediverse, I see the benefit in making the process (of key exchanging) more convenient for them.

@π₯𝐨𝐬𝐭𝐒𝐧π₯𝐒𝐠𝐑𝐭

β€œWere the private keys saved on the server side in that implementation?”

No, only the public key, shared in webfinger and the actor object which are both ideal for this purpose. In an E2EE environment the server should never see the private key because that represents a potential backdoor.

@mike Interesting! A pity I was not in Fedi when RedMatrix was in use. Well, we can't have reliable E2EE in federated environment, but we have other small improvements over centralized public networks :)

@π₯𝐨𝐬𝐭𝐒𝐧π₯𝐒𝐠𝐑𝐭 You may (or may not) be interested in Hubzilla's built-in "browser-to-browser" encryption (enabled via settings/features). It's technically E2EE but the encryption is served via JavaScript and could be thwarted by a hostile actor by changing the javascript files at both ends (difficult for most attackers but not impossible for a state actor).  This is also extensible so you can roll your own complex encryption with addons.

I created this as a proof of concept for providing E2EE in a server-based network model. If you're aware of and accept the shortcomings it actually works very well. The JavaScript crypto library used was CryptoJS for the proof of concept. If somebody was trying to re-create that work I'd highly recommend using either the Stanford JavaScript Crypto Library instead or built-in browser encryption libraries which I think now work on most browsers. The latter didn't yet exist when I initially did this work.  CryptoJS works well but there have been questions about the project's transparency.

@mike This is not now part of master branch? Or else I can't find what I'm looking for in Settings (top left). Since explaining the shortcomings to a grandmother would be a challenge, I'd still regard Fedi as mostly public. Must admit what interests me in Hubzilla right now security wise is 2fa :) The last time I checked (at the time of Friendica adding same feature) the respective addon in Hubzilla seemed to have an issue (framagit.org/hubzilla/core/-/i) and was disabled on the hub I use.

@π₯𝐨𝐬𝐭𝐒𝐧π₯𝐒𝐠𝐑𝐭 Visit the path settings/features . I'm sure there's a link to this page from somewhere but I've been out of the loop w/r/t Hubzilla development for a few years now and I don't remember where it moved to. Somebody else was working on 2FA and I've no idea what the current status of that addon is.

The fedi has "reasonable" privacy via aspects/circles/... and we've had long discussions going back many years about whether or not to treat the admin as an adversary and how precisely you define "reasonable". In a server-based platform the server admin can do anything and you can't prevent it unless you move the keys out of their realm. Since I've been building web publishing platforms as much as social networking platforms I have no problem with this. If you really want a P2P darknet it is a different technology designed for different purposes than sharing server based resources. Messaging can still be done over ActivityPub or some other federation protocol but in that case you're just using the server more or less as a 'stun/turn/ice' relay and not actually using it for storage and publishing. If that's the goal - forget about the server. Start by building the client. But you really need nomadic identity at that point or else some other way to mirror state across every device you might use. And since they might be offline, you also need a server to store everything temporarily until your device returns to the network. It's do-able but quite a challenge and requiring greater technical knowledge by the users to provide the same range of services over such a system. Text and throw-away chit-chat is fine but many of us demand a bit more of our social interfaces these days.
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!