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.
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.
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.
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.
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.
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.
We recommend that for the time being, any issues be made to the original Rocket.Chat repo, unless they specifically relate to authentication.
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.
- 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
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)
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.
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.
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.
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.
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 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.
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.
Lastly, waiting for PR to be merged to use published packages instead forks.
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).