Integration with mastodon social Mastodon / GNUSocial

[fr1t2]

See a definite need for this sweet service integrated into GNUsocial as well as mastodon.

[zQueal]

Added to #518

[Sigafoos]

I already did this in an unofficial way by tooting a signed message but it would be great to be able to have it displayed on my Keybase profile (i.e. I had to search for that way back in my timeline)

[simon-brooke]

I've done the tooting a signed message hack by following the recipe here; but it would be really nice if this was integrated into the keybase.io web app.

[lx4r]

Is there any update on this? Mastodon seems to have gained some momentum in the last days ...

[eloquence]

Indeed, per https://mnm.social/ there are now about 1.4M accounts on Mastodon (active users is probably ~1/10 of that). Moreover, given the federated model, verifying that you are indeed person X on instance Y is a great use case for Keybase. Ideally this would be done in a 1:n way, where I can link up as many accounts as I want.

[KyleRConway]

I support this. I must say that one of the first things I did when joining keybase was to try to add my Mastodon account. Was disappointed I couldn't. And, as @eloquence notes above, this would help with verification of users across various mastodon instances.

[Laurelai]

We need to be able to integrate this

[jconnary]

Would love to see this happen.

[petjal]

Seems like a good idea all around.

[codesections]

I'll also add that this would likely see a lot of use from high-profile Mastodon users (as the join the platform) because Mastodon lacks an official way to "verify" accounts—there's no equivalent of Twitter's blue check mark. So, anyone who is worried about impersonation would be very interested in keybase.

As an example of this Wil Wheaton recently registered @wilw@mastodon.cloud and had difficulty verifying himself. He eventually used the keybase workaround described above, which resulted in many new people hearing about keybase. But I'm sure the effect would have been much larger with official support, and other high-profile users might not be as willing to use a workaround.

[timnolte]

👍

[ianchanning]

There's a typo in the title: Should be GNU Social instead of GUN Social

[kenguest]

I also encourage this endeavour.

[fr1t2]

Looking at the link @zQueal posted there may be some changes needed with mastodon to get this working. Is there a way to post a verification message that could be read by keybase to verify the service?

From issue #518

Before you post your suggestions, could you please certify that the service in which you're posting for suggestion is currently able to post or display permanently public information on your behalf where anyone can view it without the need of a user account. Any information, such as a signed statement of authenticity which requires a user account severely limits the usage of Keybase.

[lx4r]

@fr1t2 Would it suffice that there is an RSS feed of every Mastodon account (accessible by adding .rss to the profile URL, e.g. this is mine)?

[Laurelai]

You can easily make public posts on mastodon if thats what you mean, you can view any public post without an account. There are also 4 slots for profile metadata that users can fill in that are displayed publicly on your profile.

[Laurelai]

Example: https://mastodon.starrevolution.org/@Laurelai/42447

[fr1t2]

Looking at this post it seems like there is more to this than it seems.

[malgorithms]

We are strongly considering this as one of our next proof types, which we'll be coming back to shortly. The last one we added was facebook and we've mostly been focusing on improving keybase recently. But yes, we've been pretty flooded with mastodon requests. We'd consider doing it even before instagram, if it were easy.

Some integrations are easy for us, and some are difficult. There are 2 server components to a proof on keybase:

• the hunter
• the scraper/verifier

The hunter is executed after a user claims they've posted a proof on service X. For example, on twitter, when a user posts a proof, Keybase's servers' hunter finds the tweet. (We can't expect the user to give us a link to it; they just tell us their username) . The hunter does this by looking through the user's recent tweets to find one that matches the proof. Depending on the service, this is a lot of work and prone to breakage. But at least it only has to happen once per proof.

Once the proof is found, it's verified by the scraper/verifier, and some quick lookup info (e.g., its URL) is stored in our database. The server then considers the proof valid.

Not that a client trusts the server! When a client wants to identify the user, they don't need to do any of the hunting, they just get the proof link from the server and verify it. The client has code to make sure the proof is cryprographically valid and verifies it was posted by the correct user, often by some combination of the URL and either the JSON reply or HTML structure of the DOM. There's a lot to get right there.

It's absolutely critical the proof can be viewed by a user without an API key and even if they're not logged into the mastodon instance. This is something we've maintained for all our proof types. So for mastodon, I'm guessing there are instances where people's profiles aren't public unless the viewer is logged in - for example as a test I just tried to go to a random profile on counter.social and it told me I had to log in.

So for keybase to do cross-instance mastodon proofs (which would be really cool) and feel very good that that our maintenance will be easy, and the proof will work for everyone, even those with higher privacy settings, we'd suggest the following very small changes to mastodon:

• a keybase proof field on profile settings. this would be sort of like the 4 key/value settings that are on there now, except it'd just be a value, and by convention it would be publicly retrievable regardless of the instance/user settings. (people would only put these strings in if they were intended to be public anyway)
• some endpoint anyone could visit (preferably JSON) where the public could check this value for a given username, and it wouldn't require any API key
• this would show up on the mastodon profile for people allowed to look at the profile, with a link to the keybase profile (and of course keybase would link to it)
• ideally give us a landing URL so we could prefill these. For example, if we send a user to whatever.mastodon.site/username/fill_keybase?value=(whatever), and they're logged in, then they land on a page with it prefilled and they just have to hit submit. We do this with many of our partners.

I imagine that's very easy, but I don't know the politics of how mastodon distributes software to its instances.

If all that worked, we could do multi-instance mastodon proofs in a BREEZE. And then all mastodon users would (1) have cryptographically-connected accounts, (2) be able to see them on profiles, and (3) have cryptographic sharing with each other inside the keybase app. And (4) keybase profiles would start promoting mastodon.

It would be pretty slick.

I just sent a DM to @Gargron on twitter but not sure if there's a better way to reach him, or if there's someone else I should talk to . Anyway, it would be a good match I think. And it would avoid all this workaround that people are talking about here.

[Gargron]

@malgorithms Thank you for the response, I am excited that this is finally moving forward!

for example as a test I just tried to go to a random profile on counter.social and it told me I had to log in

Counter.social does not federate with Mastodon, for all intents and purposes it's not Mastodon and should not affect this discussion.

One thing I'd love to accomplish is make this verification work for the ActivityPub-based fediverse as a whole and not just Mastodon. So e.g. Pleroma, Misskey, PeerTube, whenever they decide to implement whatever we come up with here.

Steps:

1. User gives you their username@domain. Check https://domain/.well-known/webfinger?resource=username@domain for a link with rel=self, now you have their profile page in ActivityPub, e.g. https://mastodon.social/users/Gargron.json, that's your hunter
2. We can implement the verification value as either one of the custom fields already used by Mastodon (but I feel it might be clunky UI-wise), or by adding a new property to the JSON, something like keybase:proof - check its value with your scraper

The last remaining step is, how do we prefill it from Keybase? We could use a hardcoded path like you said, but to make it more software agnostic, we can put a URL template in the webfinger response, similarly to how we already do with the "remote follow" URL template. So in webfinger, you'd have a link with rel=keybasePrefill and href=https://domain/settings/keybase?proof={value}, you would take that href, replace the placeholder, and redirect the user there.

[malgorithms]

to clarify step 1, would this be how it worked, assuming a user enters @foo@bar.bleah or foo@bar.bleah as a mastodon username?

a. visit https://bar.bleah/.well-known/webfinger?resource=foo@bar.bleah
b. find a rel=self entry that specifically type application/activity+json and has domain bar.bleah
c. append .json and visit that, and look inside for a keybase:proofs array entry? (or a single entry, depending on what you want to allow your user)
d. verify crypto, bleah bleah

Agreed about the webfinger response for prefill pages. that would be easy for us to handle and a nicer way of doing it.

also, once the user has done this, your mastodon instance can ping keybase to ask for other identities (and make sure they didn't post a bogus claim)....so you would hit us at a JSON endpoint whenever you want, and then on their mastodon profile you would link to us and even link to their other cryptographically connected mastodon accounts on other instances. This would be a single endpoint call to us. And it would mean you'd only display valid stuff, unlike, say twitter tweet proofs, which people can post nonsense into.

[Gargron]

@malgorithms As long as you send an Accept: application/json header, the profile page will return JSON, no URL changing necessary. That's just an easy secondary way for me to link to the JSON in the browser. But yes all correct.

[malgorithms]

ah got it. ok, we'll be discussing this internally in the very near future. If someone on our team wants to connect to you (actually or I do) for some Q&A back and forth, what's best? Your zeonfederated email?

[Gargron]

Yep.

[schmittlauch]

regarding Webfinger: As this is not a core component of ActivityPub, should we really depend on webfinger here? AFAIK Mastodon currently is not 100% ActivityPub compliant by only federating with WebFinger aware AP servers.
WebFinger is quite for the current social architecture, but there might be reasons to get rid of it.

[aendra-rininsland]

I posted a thread about why this would be amazing here: https://mastodon.social/@aendrew/100590696008271245

tl;dr please please please make this happen. Keybase is the answer to like half of the complaints I hear people raise about switching to Mastodon from Twitter.

[Gargron]

@schmittlauch Regardless of whether or not WebFinger is technically part of ActivityPub (an authentication mechanism is also not a "core component" of ActivityPub, that doesn't mean using authentication means you're not compatible. These things were purposefully left out of the spec for bureaucratic reasons), there's no way you can get these features to work in a user-friendly way without it, so why even bring this up?

[r3k2]

+1 for mastodon and other decentralized networks like "peertube" https://joinpeertube.org/en/

[schmittlauch]

@Gargron Don't worry, I don't want to stop this. I just got the impression from cwebber that stuff like HTTP signatures was left out for bureaucratic reasons, but tying accounts to an URI was done in an attempt (successful or not) to keep AP more general for other applications (e.g. calendars) or other more P2P like structures.
But if you think this will not hinder application of this to other AP servers or think it being unsignificant, go on then.

[xkr47]

Is the above procedure with webfinger something that could be ported to the rest of the ActivityPub-based fediverse as well? Or is there a need to elaborate something that can be standardized?
@Gargron, when dismissing AcitivityPub as a home for authentication matters, did it mainly refer to logging in users to the site and such or did it cover also identifying users etc on the site, like needed to exchange proof data? (Sorry for not completely grasping the context there..) What I'm thinking is; would it be a good idea to involve https://github.com/w3c/activitypub/ at some point to standardize this thing or would it be a separate standard? I think it would be good to have it standardized, perhaps even in a keybase-agnostic way.. No offense against keybase at all, it's great; just reflecting from the point of view of a potential standard..

[kaniini]

Please do not require Webfinger for this, and instead link to the profile.

There are ActivityPub softwares which do not implement WebFinger.

[CitizenPrayer]

It's been several months since any update on this topic has been given. @malgorithms and @Gargron any updates from you guys regarding this project? Is vs 2.6.0rc1 the version to test this feature with? (edit: lol I tagged the wrong guy)

[Gargron]

@ShawnEric I haven't heard anything outside of this GitHub issue. However Mastodon 2.6.0 will implement link ownership verification, independently of Keybase.

[malgorithms]

Sorry not to be posting here, but we've actually been working on this and are pretty far along, the goal being Mastodon (and other) support with minimal development. We'll have a development guide proposal ready shortly -- along with most of the code done on our side -- and if a site or mastodon instance follows the guide, they'll officially show up in Keybase's proofs list, and Keybase profiles (both in-app and on website) will link into that site and profile too. It's going to be really sweet and smoother than all our other proof types.

Also, the nice thing is it won't be like our traditional 3rd party proofs, where people can lie on the 3rd party. Verification before printing can go both ways. What I mean by this: if you see on Twitter, "Verifying myself, I am chriscoyne on keybase..." that might be a lie; Keybase wouldn't accept this connection, but of course Twitter would print the claim. But If a site follows the protocol we're proposing, then a user will (1) start on Keybase, (2) click the mastodon instance they want to prove, (3) land on the mastodon instance with just a button to click to make the connection, and (3) now the mastodon instance can simply say the Keybase username on profiles, and Keybase profiles can simply say the Mastodon instance and username. And both sides will link to each other, only if cryptographically verified by keybase. And Keybase apps will check this all without trusting the servers.

It'll be great for tying together mastodon users across multiple instances, if desired. Or proving mutual ownership between Twitter and Mastodon.

Anyway, we're almost there with a proposal and very far along in the code too.

[nealmcb]

@Gargron writes:

@ShawnEric .... Mastodon 2.6.0 will implement link ownership verification, independently of Keybase.

Thanks. Is this the feature / code you're talking about?

tootsuite/mastodon: Redesign forms, verify link ownership with rel="me" by Gargron · Pull Request #8703 ·

How might it relate to the protocol @malgorithms just described?

[Gargron]

How might it relate to the protocol @malgorithms just described?

That is the feature I was talking about. It's more like an alternative. See also

[BenLubar]

Important: to find a Mastodon user, you can't just go via the domain name of their address. The /.well-known/host-meta file has the URL template for the webfinger API, so to get to my account, you'd need to do the following requests:

• https://lubar.me/.well-known/host-meta
• https://mastodon.lubar.me/.well-known/webfinger?resource=acct:ben@lubar.me
• https://mastodon.lubar.me/users/ben

[xkr47]

I think @malgorithms and @Gargron should set up a joint account at https://patreon.com/ and start collecting (monthly) money from all the hundreds of people that want this integration to happen! At least I would happily support it!

[malgorithms]

no Patreon needed from our perspective. We've been working on this! members of our team have actually been working on the Mastodon side of the integration and should have something to announce soon...

[malgorithms]

To clarify, Keybase isn't on Patreon. But if you want to support Mastodon on Patreon, that's recommended! https://www.patreon.com/mastodon

[jonaharagon]

Looks like Mastodon is just about ready to go with this feature. Have there been any updates from the Keybase team as to when this'll go live on their end?

[fr1t2]

Closing this issues as I have just verified myself in mastodon. Great job integrating these services! Open Source at its finest.

https://mastodon.social/@just_a_warning/101983826900173420

[rugk]

One issue still: The "proof" link here:

…does not actually link to the Mastodon toot that one can toot optionally, but just to the user profile. IMHO, this is not how it should be.

[rugk]

Okay, opened a new issue for that: #3397

See also: Do not list all domains for custom verifications and Support All Mastodon Instances.

[Gargron]

…does not actually link to the Mastodon toot that one can toot optionally, but just to the user profile. IMHO, this is not how it should be.

This is a misconception. The post is optional and is not the actual proof. Linking to the profile is the correct thing to do. The proof is saved directly in Mastodon, not inside a post!

[rugk]

…but this is not at all obvious to the user.

As I said repeatedly, the technical details are likely like that, but as a user the thing I am seeing is an optional toot and some profile on a click.

As an idea, maybe when we click the link from keybase, could Mastodon somehow highlight the tick?
So it is at least obvious to the user that this is the proof. Otherwise, i, as a user, just see the profile of Mastodon, okay, I am not sure where or what the proof right now is…

Please better refer/reply in #3397.