Recent searches
Search options
[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 #FediUI tag - short and easy - for any user interface concepts of #Fediverse 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. :)
]To open closed doors, I shall start with keys.
Some use #gpg , some hate it.
Assume that #pgp 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 #Socialhome 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.
@alex they are. But it is a server-side key, which only provides internal authentication.
What I mean is, 'your', client-side PGP key.
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?
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.
@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.
@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 :)
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 (https://framagit.org/hubzilla/core/-/issues/1344) and was disabled on the hub I use.
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.