Blockstack as decentralised auth provider for Rocket.Chat

[timkinnane]

The issues below outline current blockers, gotchas and todos related to merging my “Blockparty” fork of Rocket.Chat back inline with the core project.

Most of the diffs will come from packages/rocketchat-blockstack - with a handful of UX and logic changes made in other places.

Before you begin, the only feasible way to work on this project is to first register and download the Blockstack app.

Also, be sure to reference the blockstack.js documentation.

Versions out of sync

My last merge while the project was in active development was 0.62.0-rc.2.

I haven’t had time to work on the project lately, so the first task would be addressing any merge conflicts with current development branch.

Custom auth process

The Blockstack auth process requires some specifics that are unique from standard Oauth. I’ve completed the process in this fork by adding Meteor accounts handlers, which are similar in ways to the oauth providers, but have some key differences:

• Auth requests are made to the local desktop app
• It will not currently work in native apps, due to the requirement of the companion app
• The server must provide a manifest.json - this is generated with the instance’s details
• Response includes a unique structure for user token and meta
• Blockstack user data does not contain email, I've used their ID @ blockstack.email as a stop-gap

I intend to publish a meteor package that consolidates these changes to be consumable by any Meteor app, but they should be acceptable in the meantime as is.

Admin / Service Settings

A number of admin settings are added for the package behaviour and auth request details.

The following are loaded through admin entered settings or manually populated defaults and provided as service configs through Meteor accounts helpers.

• enable - I think is currently ignored, was intended as a toggle to disable the auth method
• loginStyle - Also incomplete, would have allowed auth requests through a popup
• generateUsername - If true, would suggest a username by converting first/last name, not ideal for privacy focused community
• manifestURI - The location of the instance manifest
• redirectURI - The location to redirect to for authentication
• authDescription - Description provided in auth request screen within Blockstack

Server side routes

I added the Picker package to generate the manifest from current admin settings.

It also adds the instance’s icon file to auth requests displayed in the Blockstack app.

Avatars

Avatars are loaded directly from Blockstack.org. This included merging some work in progress from an existing Rocket.Chat branch to allow auth providers as an avatar source. The image is provided as stream, not a standard URI.

These changes might not comply with core methods without some tweaking.

The no email thing

Because Blockstack accounts do not contain an email address, yet Rocket.Chat fundamentally requires one, I've found a workaround by populating the email field with their ID @ blockstack.email.

I also modified the profile page to include some descriptive text to that effect. I think it's important to communicate what's going on here, or new users will be very confused about the format and requirements.

No other auth providers

I've customised login screens to remove other auth providers, including some hacks to disable password logins by default. The whole point of Blockstack is to decentralise a user's account and let them alone be the sole issuer.

To provide side-by-side auth from centralised providers, or even to keep their pass credentials on the server, goes against the primary principle of a decentralised app. If this is brought into core, that concern must be addressed with some considered configuration and UX changes.

I've added a user/pass login method as a subtle toggle that would only be used for admins or account recovery if some fault occurred with Blockstack authentication.

Settings defaults

Certain related settings should be forced if Blockstack auth is enabled.

• Force SSL: true
• Allow Users to Delete Own Account: true
• Require Name for Signup: false

Any recent advances to OTR or E2E encryption should also be bundled with this release, as they would be highly value valued by the Blockstack community.

Verify tokens and whitelist fields

My project was an MVP. The auth process has lots of room for improvement and the Blockstack API has also improved recently.

Please investigate what more can be done to improve the security of token handling on returned requests, such as using the Blockstack API to verify tokens and the Meteor accounts methods to whitelist only the specific fields from the returned user data that are necessary.

e.g. see rocketchat-lib/server/oath/google.js

Added dependencies

Rocket.Chat required meteor-node-stubs package to support the crypto module in client. I think this is because the Node library bundled with Meteor/Rocket.Chat does not contain the full set up Node utilities, such as crypto.

There may be a lighter work around for this issue, such as explicitly building Node with the crypto module, instead of adding the entire meteor-node-stubs package.

Questions for Blockstack

In order to merge and create a community for Blockstack within Rocket.Chat, we need to establish some objectives with their input.

• Can Blockstack assign resources (at least a direct contact), with the intention of overcoming current challenges of merging the Blockparty fork with Rocket.Chat core
• Will Rocket.Chat Cloud provide and manage the infrastructure and what level of service do they require
• Will the platform continue under the Blockparty identity, as a distinct product / app on their homescreen, or exist simply as the Blockstack community chat (similar to existing forums)
• What is the timeline for the community migration
• What’s the expected size and frequency of use for the larger community
• Will a dedicated resource be required to manage the community, support contributions and collaborative development