Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Keybase integration #10297

Merged
merged 42 commits into from
Mar 18, 2019
Merged

Add Keybase integration #10297

merged 42 commits into from
Mar 18, 2019

Conversation

Gargron
Copy link
Member

@Gargron Gargron commented Mar 16, 2019

Allow users to setup a cryptographic connection between their Mastodon profile and their Keybase profile. Keybase is extracted into a polymorphous ProofProvider interface to potentially allow other providers to be supported and minimize "hardcoding" a specific provider.

image

image

image

Performance notes:

  • One synchronous HTTP request is performed when proof is being saved to check if the signature hash is actually valid on Keybase
  • One asynchronous HTTP request is queued right after the proof is created to check if the proof went live on Keybase (and can therefore be showcased)
  • One synchronous HTTP request is performed to retrieve the avatar URL from Keybase for each proof, both on the proof index as well as on new proof page
  • One synchronous HTTP request is performed to check if the proof is still live and valid whenever the proof index is loaded

Resolve #10013


def index
@proofs = AccountIdentityProof.where(account: current_account).order(provider: :asc, provider_username: :asc)
@proofs.each(&:refresh!)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xgess Is this necessary? n synchronous HTTP requests on page load is not great. I would think the worker queued after the proof is saved would take care of checking if the proof is live

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The refresh! do not seem to be synchronous (it spawns a worker?), but I question the need to trigger a refresh each time that page is visited.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does worker_class.new.perform(@proof) which is synchronous

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the main reason i had to do this was that there's nothing currently built on the mastodon side to recognize remotely revoked proofs. i thought it might be weird if a user revokes a proof in keybase, then days later still sees it as live in mastodon until the first refresh. we had it as a note to talk about / build something that might let keybase inform mastodon a proof is revoked, or build a rake task for mastodon to check and invalidate revoked proofs.

i'm flexible on this though. if you want to change it to be async, i think that's reasonable.

Copy link
Contributor

@ClearlyClaire ClearlyClaire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This review doesn't really cover the correctness of the implementation wrt. keybase's protocol itself, as I have not read it, but only code quality and some concerns.

It seems fine overall, but I'm a bit concerned with the various HTTP calls, some of which synchronous. This shouldn't be a major issue, but still.

Also, will this work for any instance, or do instance admins still need to get approved by keybase?

Wouldn't it make sense to have a setting to enable or disable this feature? (Especially if the admin needs to take action wrt. keybase for it to be usable)

config/settings.yml Outdated Show resolved Hide resolved
@proof = current_account.identity_proofs.new(
token: params[:token],
provider: params[:provider],
provider_username: params[:provider_username]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resource_params?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah no, the difference to resource_params is that these are like ?token=??? while resource_params after form submission are nested


if verifier.valid?
@proof.verified = true
@proof.live = false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should ActiveRecord validation really have side-effects?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose you could argue that verified could be set before_save which would not happen if validation doesn't pass, but I am not too unhappy with how it is

app/views/accounts/_bio.html.haml Outdated Show resolved Hide resolved

def index
@proofs = AccountIdentityProof.where(account: current_account).order(provider: :asc, provider_username: :asc)
@proofs.each(&:refresh!)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The refresh! do not seem to be synchronous (it spawns a worker?), but I question the need to trigger a refresh each time that page is visited.

@Gargron
Copy link
Member Author

Gargron commented Mar 18, 2019

Also, will this work for any instance, or do instance admins still need to get approved by keybase?

Wouldn't it make sense to have a setting to enable or disable this feature? (Especially if the admin needs to take action wrt. keybase for it to be usable)

I was assured no proactive action would be necessary on the part of the instance admin

@Gargron Gargron merged commit 9c4cbdb into master Mar 18, 2019
@Gargron Gargron deleted the feature-keybase branch March 18, 2019 20:00
@witcheslive
Copy link

I have updated witches.live to the master branch which has support for this, do you need any help testing it, and if so how could I go about doing that?

@cnf
Copy link

cnf commented Mar 23, 2019

Is there any documentation on how to use this as a user? I can't seem to find it.

@Gargron
Copy link
Member Author

Gargron commented Mar 24, 2019

@cnf It is not live on Keybase's side yet. Other than that, there is nothing to do on Mastodon, you initiate the process from Keybase.

@cnf
Copy link

cnf commented Mar 24, 2019

Right, thanks!

hiyuki2578 pushed a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
* create account_identity_proofs table

* add endpoint for keybase to check local proofs

* add async task to update validity and liveness of proofs from keybase

* first pass keybase proof CRUD

* second pass keybase proof creation

* clean up proof list and add badges

* add avatar url to keybase api

* Always highlight the “Identity Proofs” navigation item when interacting with proofs.

* Update translations.

* Add profile URL.

* Reorder proofs.

* Add proofs to bio.

* Update settings/identity_proofs front-end.

* Use `link_to`.

* Only encode query params if they exist.

URLs without params had a trailing `?`.

* Only show live proofs.

* change valid to active in proof list and update liveness before displaying

* minor fixes

* add keybase config at well-known path

* extremely naive feature flagging off the identity proof UI

* fixes for rubocop

* make identity proofs page resilient to potential keybase issues

* normalize i18n

* tweaks for brakeman

* remove two unused translations

* cleanup and add more localizations

* make keybase_contacts an admin setting

* fix ExternalProofService my_domain

* use Addressable::URI in identity proofs

* use active model serializer for keybase proof config

* more cleanup of keybase proof config

* rename proof is_valid and is_live to proof_valid and proof_live

* cleanup

* assorted tweaks for more robust communication with keybase

* Clean up

* Small fixes

* Display verified identity identically to verified links

* Clean up unused CSS

* Add caching for Keybase avatar URLs

* Remove keybase_contacts setting
messenjahofchrist pushed a commit to Origin-Creative/mastodon that referenced this pull request Jul 30, 2021
* create account_identity_proofs table

* add endpoint for keybase to check local proofs

* add async task to update validity and liveness of proofs from keybase

* first pass keybase proof CRUD

* second pass keybase proof creation

* clean up proof list and add badges

* add avatar url to keybase api

* Always highlight the “Identity Proofs” navigation item when interacting with proofs.

* Update translations.

* Add profile URL.

* Reorder proofs.

* Add proofs to bio.

* Update settings/identity_proofs front-end.

* Use `link_to`.

* Only encode query params if they exist.

URLs without params had a trailing `?`.

* Only show live proofs.

* change valid to active in proof list and update liveness before displaying

* minor fixes

* add keybase config at well-known path

* extremely naive feature flagging off the identity proof UI

* fixes for rubocop

* make identity proofs page resilient to potential keybase issues

* normalize i18n

* tweaks for brakeman

* remove two unused translations

* cleanup and add more localizations

* make keybase_contacts an admin setting

* fix ExternalProofService my_domain

* use Addressable::URI in identity proofs

* use active model serializer for keybase proof config

* more cleanup of keybase proof config

* rename proof is_valid and is_live to proof_valid and proof_live

* cleanup

* assorted tweaks for more robust communication with keybase

* Clean up

* Small fixes

* Display verified identity identically to verified links

* Clean up unused CSS

* Add caching for Keybase avatar URLs

* Remove keybase_contacts setting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api REST API, Streaming API, Web Push API ui Front-end, design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants