@mapache @badgefed@vocalcat.com @badgefed@badges.vocalcat.com @julian

Okay, okay then

Inspired by @dajb I will use 'Social verifiable credentials' as the category for #BadgeFed in the new taxonomy I am creating for delightful-fediverse-apps curated list. Which I am in the process of giving a complete makeover and revitalization. Hope to have it live soon

https://delightful.coding.social/delightful_fediverse_apps

PS. Was also talking badges & credentials with @RyunoKi today, regarding #Keyoxide roadmap.

@shoppingtonz @a @keyoxide #keyoxide

A ha! I think I've found the problem. I created a test ASP profile on keyoxide with just this mastodon account as the claimed identity, done two different ways:

https://keyoxide.org/aspe:keyoxide.org:ZPZNQV5T2BDHSUVEFUINFRS4B4

The first way is the standard way of adding a claim to the ASP profile, by selecting the dropdown of "Mastodon" and putting in your username. This produces a `rel="me"` URL on the profile page that looks like this:

<a rel="me" href="https://tenforward.social/@aspensmonster" aria-label="link to profile">https://tenforward.social/@aspensmonster</a>

This follows the exact format that Mastodon docs say they are looking for in a verification link, and the Mastodon client will respect this and show the link as verified (see my "Keyoxide ASP" metadata block on my profile for proof).

However, if instead of "Mastodon" in the claim creation dropdown I pick "Manual input", and then put in a link to a specific *post* on my account as the claim, then the generated URL is instead:

<a rel="me" href="https://tenforward.social/users/aspensmonster" aria-label="link to profile">https://tenforward.social/users/aspensmonster</a>

Notice how instead of `$instance/@$user`, the format is `$instance/users/$user`. Since this is not what Mastodon expects the format of the verification URL to be, it does not show the URL as verified.

I believe that the `/users/` approach is a more general activitypub approach, and is probably more "AP standard." However, Mastodon specifically doesn't seem to consider that as equivalent.

Three options:

1. Mastodon accepts the /users/ approach and considers the link verified (probably won't happen)
2. Keyoxide tries to determine if the specific AP implementation is Mastodon, and tweaks the URL to be in the expected format (not ideal)
3. Have ASP users only use profile claims and not post claims for Mastodon if they want Mastodon's green checkmark (easiest).

For @shoppingtonz , the easiest thing for you to do would be to remove the post claim that you have on your ASP profile, and use the standard "Mastodon" dropdown instead. Then, the green verification bar and check should work for you too.

@lynnesbian #keybase may be dead in the water, but #keyoxide is still around at least

@Xeniax Totally nerdsniped :D I'd love to be a part of the study.

I don't think that #KeyServers are dead. I think they evolved into Verifying Key Servers (VKS), like the one run by a few folks from the OpenPGP ecosystem at https://keys.openpgp.org/about . More generally, I believe that #PGP / #GPG / #OpenPGP retains important use-cases where accountability is prioritized, as contrasted with ecosystems (like #Matrix, #SignalMessenger) where deniability (and Perfect Forward Secrecy generally) is prioritized. Further, PGP can still serve to bootstrap those other ecosystems by way of signature notations (see the #KeyOxide project).

Ultimately, the needs of asynchronous and synchronous cryptographic systems are, at certain design points, mutually exclusive (in my amateur estimation, anyway). I don't think that implies that email encryption is somehow a dead-end or pointless. Email merely, by virtue of being an asynchronous protocol, cannot meaningfully offer PFS (or can it? Some smart people over at crypto.stackexchange.com seem to think there might be papers floating around that can get at it: https://crypto.stackexchange.com/questions/9268/is-asynchronous-perfect-forward-secrecy-possible).

To me, the killer feature of PGP is actually not encryption per se. It's certification, signatures, and authentication/authorization. I'm more concerned with "so-and-so definitely said/attested to this" than "i need to keep what so-and-so said strictly private/confidential forever and ever." What smaller countries like Croatia have done with #PKI leaves me green with envy.

@katzentratschen das war #Keybase und ist #Keyoxide heute...

@hyperreal From having implemented a #keyoxide claim verification service once, I can say that IRC and XMPP were far and away the most flaky endpoints to talk to, followed by Matrix. Ultimately, chat programs aren't really optimized for constantly serving up old messages at random (what Matrix claim verification does IIRC) and bots aren't always well-behaved (what IRC claim verification does IIRC). XMPP at least has the concept of storing non-message data (from some XEP or another; can't remember which) though.

@prami Keybase has been on life support for a while now. Thankfully, there's #KeyOxide as an alternative.