BlockParty

Blockstack + Rocket.Chat == BlockParty

The first open source community chat platform to implement fully decentralized user authentication.

BlockParty is a fork of Rocket.Chat. The Ultimate Open Source Chat Platform - Now decentralized!

The master master branch is stable for production and based off Rocket.Chat releases. We intend to sync upstream features when they are stable, like end-to-end-encryption.

Why Rocket.Chat

BlockParty implements a custom authorisation process through Blockstack. However, Rocket.Chat already has an ideal feature set for the Blockstack community:

• Off The Record (OTR) message encryption (optional)
• MIT licence, can fork and run your own private instance
• Two-factor authentication (2FA)
• Embed real-time chat widgets
• Real-time translation
• Web, desktop and mobile
• Integrations, data importers and powerful APIs

See here for more on the virtues of Rocket.Chat as a messaging app for the decentralised community.

Usage and Docs

See the Rocket.Chat master readme for information on modifying and deploying. The descriptions below will only detail the variations on this fork, as it relates to Blockstack and decentralization features.

Demo already!

BlockParty.chat is the demo instance. The identity and design is an example of how Rocket.Chat can be customised. When rolling your own instance, there’s no requirement to retain branding or terms from Rocket.Chat or BlockParty.

Mobile Usage

Rocket.Chat provides an optimised experience within mobile browsers.

They also provide open source apps for devices, including Cordova apps wrapping the web interface and native apps on both Android and iOS.

These apps can be forked to implement Blockstack auth with further development and some collaboration with the Blockstack team, related to their mobile support roadmap.

Ongoing Development

This project was launched as an entry to Blockstack’s 2018 Signature Bounty to Decentralize Communication.

However, being an open source project it will continue to add features and overall performance, stability and experience enhancements. As a direct fork of Rocket.Chat it can stay in-sync with upstream releases, but also accept contributions from the Blockstack community.

Contributions

We recommend that for the time being, any issues be made to the original Rocket.Chat repo, unless they specifically relate to authentication.

What’s the Diff

Rocket.Chat default behaviour has been modified to suit the decentralised principles of Blockstack.

These settings are mostly applied in the rocketchat-blockstack package. In principle it is intended to be used instead of, not along with, centralised auth providers. However it would be possible to have Blockstack authentication in any Rocket.Chat instance.

Most of the authentication logic is not unique to Rocket.Chat. It is an objective of this project to streamline adaptation of the Rocket.Chat auth provider into an all purpose Meteor auth provider, enabling any other Meteor apps to decentralize accounts via Blockstack signin.

Some configuration defaults have also been changed to be fit for purpose:

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

The password login is available for admins or to resolve Blockstack authentication issues. Users can set their own password, but can only register via the Sign in with Blockstack button.

Roadmap

• Appoint community contribution and management team
• Forked iOS and Android apps specifically for BlockParty instances
• Full auth documentation and debug logging to encourage further contribution
• Repackage and publish as generic Meteor package accounts-blockstack
• Publish tutorial app for Blockstack auth in Meteor
• Use Blockstack file upload package for assets storage (similar to S3 package)
• How-to-fork and setup guides submitted to rocket.chat/docs
• Support other encryption protocols like OMEMO (conversations.im/omemo) #36
• Use Let’s Encrypt to automatically issue SSL certificates for instances
• Bot onboarding / welcome and integration with other Blockstack services

Minor Issues

The following will be migrated into GitHub issues for further tracking…

• Optional popup instead of redirect to Blockstack login
• Switch back to official blockstack.js dependencies when PRs resolved
• Remove unuesd packages and settings for other auth/SSO providers
• Prevent uploading avatars, only link from Blockstack ID
• Fix all assumptions in code that users will have email address
• Add scopes to settings (not currently necessary)
• Pending login animations / button state / pause client processing etc
• Put all dependencies into meteor package, not app root package.json
• Cater for linking users with multiple or changed Blockstack IDs
• Set whitelisted fields (see rocketchat-lib/server/oath/google.js)

Gotchas!

First User Admin

Unless you’ve set the environment vars to add default admin password, the first user to access the site will become admin. Make sure it’s you, before making your instance public.

Password Logins

It’s still possible for users to login via password, to aid in recovery from bad settings that might break Blockstack authentication and would otherwise leave users locked out. However, the registration process is removed so that users must all be created with a Blockstack ID first, then can access their profile to set a password. If the admin is created on build with environment variables, they will always be able to enter by password and manually reset other user’s passwords.

User Emails

Rocket.Chat users require email, due to a number of tightly coupled methods that were not written with emails as a conditional field. This needs some quick fixes on this fork, but also a longer term approach to incorporate into Rocket.Chat as a core design principle, to allow future integrations of upstream changes without creating more bugs by assuming existence of user emails.

Theming Your Instance

There’s a blockparty-theme package that could be used as an example of how BlockParty’s visual customisations and default settings were achieved. Custom CSS can also be set by admins and the Rocket.Chat documentation has a section on theming your instance.

Security Note

User data in tokens is not verified on login currently. This may have security implications and should be resolved with advice from the Blockstack community.

Offline Access

Offline access really hasn’t been considered beyond writing this note. An approach might use RoutePolicy to process some user events offline, which can probably be done safely without preventing access to offline accessible parts of the app.

Performance

Rocket.Chat required meteor-node-stubs package to support the crypto module in client. This is probably unnecessary if a smaller solution can be found to work around this issue. The optimal approach would actually be refactoring the Blockstack node modules as a Meteor package, thus reducing dependencies and build complications.

Lil Hacks

Lastly, waiting for PR to be merged to use published packages instead forks.

• https://github.com/blockstack/blockstack.js/issues/308
• https://github.com/blockstack/jsontokens-js/pull/14

Thanks!

To @Sing-Li for promoting the bounty project, being an awesome community advocate and pushing me to give it a shot!

To @rurri for shedding light on the darker corners of Meteor authentication processes - in this article.

To @amycleary for putting up with my late night tapping and general dissociation while working on this (ok, all the time).