Skip to content

Decentralized

Gregory Magarshak edited this page Jan 22, 2017 · 9 revisions

About

This document contains information on how the decentralized Qbix Platform will work.

Definitions

  • An app is website with a back-end server, including a database. It may be entirely built on the Qbix Platform or just use Platform.js for authentication.
  • A domain is as normally defined. It typically hosts one or more databases for users, streams, etc. Domains may install various apps.
  • The Qbix installer is used to install and update various versions of apps and plugins, which connect to these databases.
  • A community is a user in an app's database which represents a community or organization.
  • The roles in a community are its contact labels such as "$AppName/admins" for admins.
  • A client is an interface, typically a webview that supports Javascript, that is designed to interact with one or more Qbix apps.
  • A device represents an endpoint that can receive notifications, typically a native app on a mobile phone, tablet, or other device.
  • A home app is an app that the user often uses for authentication and managing contacts.

Features

U: Users will be able to ...

  1. Sign into any app A in one click/tap by authenticating with another app B. The user ids on A and B will be completely different, preventing easy tracking of the user between domains.
  2. Share their user id on B with whoever they want. They may share with certain contacts in some address book, such as all contacts on A under the label "Users/friends". They may also share with contacts who chose to host on some other home app C or D. This notifies the friends that you've signed up.
  3. Have B tell A all the userIds on A that have been shared with the user, thereby connecting with friends and seeing all the content and activity they have contributed already, rather than being alone on a site.
  4. Send private messages to each other across domains and home apps, and encrypt some data to be decrypted only by a user's clients and devices, and handled by scripts which run a sandboxed Javascript environment.
  5. Have their user name and local streams displayed in iframes hosted by B until such time as they want to import these streams into B using an oAuth flow. B can also subscribe to notifications for when these streams change, and pull the changes.

C: Communities will be able to ...

  1. Release their own apps on the app stores, if they want, or use a web app.
  2. Create widgets that other apps can add, which will use feature U5 to show a personalized and social experience seamlessly without even a single click/tap to log in.
  3. Import spreadsheets and invite batches of people (e.g. class of 2017). Get notifications and reports as they accept invitations and sign up.
  4. Host aggregators (of events, photos, or an entire search engine or social posting board) and subscribe to changes in the linked resources.
  5. Host multiple sub-communities in their database, and release apps for other communities to install. For example a "Phi Beta Kappa" or "Chess" app that works across universities.
Clone this wiki locally