A moderator asks someone to disclose an attribute of their real identity. The recipient provide the requested attribute, using Yivi to attach a cryptographic proof.
In the last update I introduced a demo of attribute disclosure. I have since completed the main TODO there, making the disclosure flow happen on the recipient's account. (In the first demo the moderator's role and the recipient's role both took place in the same login session in the same account.)
This week I have been thinking about how we will need to improve the user experience, or flow, of this disclosure request and response.
Writing the dialogue boxes and associated logic by hand was tedious and buggy. Rapid prototyping would be helpful. I decided it's time for me to learn a better way. Being new to UI design and fervently open-source principled, I searched for a FOSS solution and found Quant-UX.
This month I have been building a PubHubs-specific feature, the ability for a moderator to ask a someone to disclose an attribute of their real identity.
When a person signs in to PubHubs hub through the Yivi verified credentials system, initially they are allocated a pseudonymous user identifier, for example @123-321:testhub.matrix.host. From this pseudonym, not even an operator or moderator of the hub can discover the user's real identity.
A moderator may wish to ask a user to confirm their real identity, to some degree. Through Yivi it is possible to ask a user to reveal a cryptographic proof [1] of one or more of their identity attributes. Some common attributes are one's real name, physical address, or email address. An attribute could also be something like “age is at least 18 years”.
As a member of this Organisation, I would like to thank you for your efforts to keep your members updated, and for periodically re-evaluating the best way to do so.
Unfortunately you have lost me by asking me to join Mr Zuckerberg's Facebook club in order to receive your information.
I would like to invite you in your next reevaluation to consider providing your primary communications through a channel that is in the nature of a public utility, not a private members club.
I will explain why and how.
(I am professionally involved in the subject area of public non-proprietary communications channels.)
Contents:
A personal, heart-felt tirade on why this is so wrong.
Professional advice on the right way to communicate.
Facebook is Not a Public Utility
I am aware lots of people have begun to treat Facebook as if it were a public utility. Doing so is a mistake and causes deep problems. [[1]][ellis1]
I once thought I was making a neutral choice to shop at Amazon, and that their wish list was a nice convenience.
Just like I one thought Google was my friend, and signed up for their “free” email. I deeply regretted that and have now deeply deGoogled.
Nowadays I recognise a greedy mega-corp when I see one, with everything wrong that goes along with that, and so I shut down my wish list there and almost completely avoid shopping there.
Android or iPhone — either Google or Apple delivers our messages — surely? You don't accept that?
Time I Learned: there are freedom-respecting phones.
People who do not want to depend on Google or have them control our devices are using android-compatible but not google-controlled phones, a.k.a. “degoogled phones”. We have been asking (ourselves) for several years if we can have google-free push notifications. Thanks to the developers of the UnifiedPush standard, the answer is now, “yes!”
UnifiedPush open-standard push messaging complements degoogled android-compatible phone OS's such as LineageOS.
People who do not want to depend on Google or have them control our devices are using android-compatible but not google-controlled phones, a.k.a. “degoogled phones”. We have been asking (ourselves) for several years if we can have google-free push notifications. Thanks to the developers of the UnifiedPush standard, the answer is now, “yes!”
The open standard UnifiedPush.org has now been created. While not a large number yet, a useful handful of apps already support UnifiedPush, including several matrix and fediverse apps. For its servers and the associated client-side “distributor” component, there are multiple successful implementations deployed.
More and more I find myself using the fediverse (based on ActivityPub) alongside Matrix, and the two protocols complement each other nicely in some ways. In other ways their differences seem needless and jarring, only getting in the way. I'd like to be able to offer my contacts the free choice of which protocol to use, depending on what kind of communication they intend (public-ish versus private or group-ish), without everything else being different — especially the user identifier/addressing but also many lesser issues such as the existence of user profiles.
I have long remained hopeful we'd get use profiles eventually. Conceptually it's not a big deal. So where are we now and where are we going?
