Streams Plugin – Access Control

[Qbix]

This article is aimed at a more general audience. Software developers can read more technical information in the developer guide.

The Streams plugin deals with managing data in the system and updates to it. Each piece of data, represented as a Stream, is published by a User in the system (see Users plugin). The publisher be an end-user account, or a Community.

By default, Streams in Qbix start out as private, with only their publisher having any kind of access to them. But, the system has many standardized mechanisms to allow other users to gain specific Access to the Streams. They include:

• public access involves readLevel, writeLevel, adminLevel and permissions fields directly saved on each stream. You should put here the minimum access that you want everyone to have, often it is 0.
• user-based access involves the same fields in Streams_Access table rows (with -1 meaning “ignore”), with a ofUserId field, identifying a specific user in the system. This can be also be used to downgrade a user’s access to a stream, or “ban” them.
• role-based access involves the same fields in Streams_Access table rows with a ofContactLabel field, naming the role relative to the stream’s publisherId (friends, directors)
• participant-based access involves the same fields in Streams_Access table rows, but with a ofParticipantRole field, naming the role of a participant in the stream (presenter, speaker)
• template access is access that is copied from a template named after the stream type with a trailing slash (e.g. Chess/game/) when a new stream of a given type is created
• mutable access is access named with a trailing asterisk (e.g. Chess/game*) and is fetched every time a stream’s access is calculated, which allows modifications to access levels for all streams of that type, whether new or already created
• inherit access from other streams, even across publishers: e.g. images placed in various albums, members in a community allowing its admins to access the streams they publish, or ban users the community bans.

Web Server Interface

The Streams plugin takes care of access control for you. It includes back-end PHP scripts handling HTTP actions such as GET, POST, PUT, DELETE to work with streams, as well as versions for batch-getting streams, etc. They don’t trust clients, and actively check the access levels for what the logged-in user can do with a stream. Additional restrictions for clients, regardless of these permissions, can be found in configs named Streams/types/*/create and Streams/types/*/post .

Qbix also supports headers like X-Accel-Redirect for web servers like NginX, which truly allows only authorized users to access specific Streams, even if links to them are shared. This enforces restrictions on access to gated resources (PDFs, videos, etc.) e.g. content uploaded for paid courses. The actual access is then managed by the Qbix Platform.

Access Levels

The Streams plugin standardizes access levels into four categories:

readLevel can be:

• 0=‘none’, can’t even see the stream is there
• 10=‘see’, can read the stream’s title and icon, but nothing beyond that
• 20=‘content’ can read the stream’s content, attributes and any extended data
• 30=‘participants’ can see the users participating in the stream
• 40=‘messages’` can see the messages those users have been posting

writeLevel can be:

• 0=‘none’, can’t affect the stream at all
• 10=‘see’, can join the stream as a participant, and subscribe to updates
• 13=‘vote’, can vote on things about the stream
• 14=‘suggest’, can privately suggest actions for stream managers to consider
• 16=‘ephemeral’, can send ephemeral payloads to the stream to be broadcast
• 18=‘contribute’ can join real-time broadcasts, such as videoconferencing over WebRTC
• 20=‘post’ can post durable messages which are broadcast immediately
• 23=‘relate’ can relate other streams (e.g. posts to a forum, images to an album)
• 25=‘relations’ can manage relations, e.g. changing their weights and sorting
• 30=‘edit’ can post messages to edit stream content immediately, posting messages
• 35=‘closePending’ can post a message requesting to close the stream
• 40=‘close’` closes the stream, but it’s kept around and removes all relations

adminLevel can be:

• 0=‘none’ cannot do anything related to admin / users
• 10=‘tell’ can tell others about the stream’s publisher, icon, title and your participation and role in it
• 15=‘share’ can share the stream’s actual content with others
• 20=‘invite’ can create invitations for others, granting access levels up and including to their own
• 30=‘manage’ can approve posts, and give people adminLevel < manage
• 40=‘own’ can give people any adminLevel <= “own”

permissions

• This is just an array of permissions, which are strings of text representing abilities that for some reason might not fit the above standardized framework.

Note that publisherId of a stream basically has the maximum levels in the stream. Streams can be published by a community (whose userId begins with a capital letter, e.g. userId="BankOfAmerica") or a regular person (e.g. userId="uzkchajq").

A typical approach is for community admins to grant roles to other users, or for a person to manage their relationships to other users. Then, the Streams_Access rows already installed in the database give users various access to streams. The ofContactLabel and ofParticipantRole fields can tie access to roles in a community, or a specific stream.

Invites

The Streams/participants tool shows avatars of users participating in a stream, and these avatars might display various badges, etc. to show their role in the community, or their role as a participant. If the logged-in user has testAdminLevel("invite"), then the tool shows a fading array of pluses an the “Invite” button, which all lead to an “Invite” dialog:

People are able to use this dialog to invite others to the stream utilizing a variety of methods, including posting invite links on social media, or emailing them.

Clicking “Select Contacts” allows the user to select specific contacts to invite. In this case, invites are privately sent by the Qbix server to a specific email address or mobile number, each with a unique link that can only be received by that user.

Anyone visiting the secret private link will automatically receive a user account with that email address or mobile number verified, cutting down on the number of steps that normally need to happen. We call this innovation “1-click invites”.

Everyone else will see something like this, if they’re not already logged in:

Either way, even if the invited user hasn’t logged in yet and accepted the invite, their session is already temporarily granted the readLevel from the invite itself, so they can see what they are being invited to. They can see the videos and chats playing in the background, even with sound, motivating them while going through the on-boarding process and granting permissions to the website:

They can either log in with an existing account:

or register a new user account. If they enter an email that’s already been used before but never verified, they’ll be invited to re-send that activation to claim the account. Otherwise, they’ll be registering a completely new account:

This is followed by the on-boarding process:

And once they’re in, they can start participating right away!

Notice, by the way, that Qbix Platform can automatically search Google and Facebook for a picture matching the name given. They can later change the picture in their profile, but for well-known individuals, this cuts down on the number of steps they had to do, such as selecting a picture on their phone:

Roles and Permissions

People can have different roles in a community, which admins can grant and revoke by clicking on that section of their profile. They can also grant roles by sending invites that are accepted by their recipients.

And when admins invite someone, they can also click the button to select additional roles to grant to a user.

Thanks to Intercoin’s Community DAO Smart Contract, our platform can even manage Web3-based roles stored on a blockchain like Ethereum or Polygon.

Imagine a community having its own smart contracts, selling roles on a blockchain, and allowing its own site and others, to query the membership information at any time, to determine whether or not to grant access to certain streams of data. Sites around the Web could implement gated content, paywalls, paid subscriptions, and much more. Those using Qbix Platform to power their site could establish granular access control out of the box, as described in this article. Meanwhile, the entire time, Intercoin’s smart contracts can be used to securely manage valuable data such votes, balances, or important roles in a community:

Intercoin DeFi: CommunityContract

Qbix is working on a decentralized ecosystem where communities pay each other for digital content on behalf of their members, using micropayments. This can help revolutionize the business models for journalism, igital media, open source software, and much more:

Qbix: Community Operating System