Difference between revisions of "ACL"
|(7 intermediate revisions by the same user not shown)|
|Line 1:||Line 1:|
|Line 250:||Line 254:|
Latest revision as of 08:44, 22 June 2022
Access Control List - explanation of privileges for Owners, Apps and Users.
ACL table for Ethora platform
Access Rights table.
|files.delete||TRUE (self)||TRUE (self)||TRUE (self)|
|files.get||TRUE (self)||TRUE (self)||TRUE (self)|
|files.post||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.create||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.delete||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.graph||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.ctrl.history||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.ctrl.itemsBurn||TRUE (self)||FALSE||TRUE (self)|
|tokens.ctrl.itemsCreate||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.ctrl.itemsTransfer||TRUE (self)||FALSE||TRUE (self)|
|tokens.ctrl.mint||TRUE (self)||TRUE (self)||TRUE (self)|
|tokens.ctrl.transfer||TRUE (self)||TRUE (self)||TRUE (self)|
|user.ctrl.actions||TRUE (self)||TRUE (self)||TRUE (self)|
|user.ctrl.changePassword||TRUE (self)||FALSE||TRUE (self)|
|user.ctrl.deleteEmails||TRUE (self)||TRUE (self)|
|user.ctrl.forgot||TRUE (self)||TRUE (self)|
|user.ctrl.getEmails||TRUE (self)||TRUE (self)|
|user.ctrl.login||TRUE (self)||TRUE (self)|
|user.ctrl.profile||TRUE (self)||TRUE (self)||TRUE (self)|
|user.ctrl.put||TRUE (self)||TRUE (self)|
|user.ctrl.restoreXmpp||TRUE (self)||TRUE (self)|
|wallets.ctrl.updateDefaultToken||TRUE (self)||TRUE (self)||TRUE (self)|
Network context explained for specific entities
- Network: Dappros Platform infrastructure that shares the same Application, Blockchain and Chat infrastructure (servers). By default, all Applications run on the same Network unless their Owners have made arrangements to host on their own dedicated Network.
Users and Applications
Login & Sign up
Users can login into any Apps within the same Network.
Social Sign On (SSO): Facebook, Gmail and Apple sign in creates a User account in the Ethora backend (Dappros Platform). After this is done, same account is reused when client application detects an attempt by a user to do a SSO login. These accounts persist across the Network which means a new account is not created when user does a SSO login with same social network profile in a new client-side application when SSO has already created a profile for that user from another application in the Network.
Login/E-mail + Password sign in:
Same as for SSO - login/e-mail is unique across network. Once account is created, users can re-use it across all client-side applications in the Network.
Users can read information from any Apps / entities within the same Network (see ACL table above - all TRUE applies to all apps within the Network)
Users write updates apply to user accounts across all Applications within the same Network (as User profile is global, once User updates their profile in one Application, it updates across the whole Network and is reflected in all Applications)
Files and IPFS content is accessible across all Applications within the same Network.
This means that files content and attachments created in one Application are accessible by the users of other Applications within the same Network (provided that the IPFS link is known to them, and also that no end-to-end encryption is enforced by the specific Application that has been used to store the file).
Chat rooms are accessible across the same Network. Rooms don't belong to any particular Application context.
Different Applications within the same Network are expected to allow their Users to join, read and rite into any chat Rooms within the same Network.
Only difference across Applications in relation to the chat rooms may be the local Application settings such as "Official" rooms that are sticky, or any local UI, message parsing and notification settings.
Tokens (Items and Coins)
All tokens such as Items (NFT) and Coins (ERC-20) are accessible to all Applications across the Network.
Applications should display Balances and Transactions of the users showing their global balances.
Note: Applications (in their own UI) may choose to filter out certain transactions if they aren't useful for their users. For example, any technical transactions generated by the platform or other Applications.
Note: Applications (in their own UI) may choose to modify the display of the tokens or balances, for example they can choose to call the DP Coin in their own name, for example "<Application name> Coin".
Gamification / Rewards
All Applications, when created, by default receive 10,000 DP Coins into their balance from the Platform (directly or via the Reward Station smart contract).
Daily activity bonus
All Applications reward users with 5 Coins for every DAU (activity during a 24h period).
Note: this means same user can receive multiple rewards for their daily activity from multiple Applications if they log in via different Applications during the same day.
Note: Applications may display "DP Coin" in their own name in user balances and transactions, for example "<Application name> Coin", in order to avoid confusing users in the ecosystems which aren't aware of how the infrastructure works and who don't want to be overloaded with technical / token economy complexities.
Registration bonus of 100 Coins is paid to the user by the app that first registers this user in the current Network. All other Applications will recognize the user as already registered so will simple sign in the user, without paying the 100 Coins bonus.
Coin display name
Users may also receive other DP Coin rewards and transfers, for example the "crypto likes" from other users for their content, direct transfers, payments for Items, bots interactions etc. In all of these cases their transactions and their balance is the same globally across all Applications of the same Network, however the display name for "DP Coin" may vary from Application to Application.
Rooms / Spaces roles
Chat Rooms / Spaces management roles are derived from those of the XMPP protocol. In our platform, the following roles are available for users and bots:
- Owner - the user who has created the Room / Space
- Admin - user(s) who were given Admin access to Room / Space
- Moderator - users(s) who can ban other users in the Room / Space
- Participant - all users without additional privileges
Assigning Admins and Moderators
Owners can assign other users to be Admins and Moderators.
Admins can assign other users to be Admins and Moderators.
Moderators cannot assign other Moderators.
Owners, Admins and Moderators can see "Ban this user" button in the chat interface (long tap menu).
Any user can be Banned for a period of 3h, 1 day, 1 week and Forever.
Ban exists within a Room/Space context (so user banned in one Room, can read/write in other Rooms).
Any banned users cannot write into the Room or read from the Room where they are banned anymore, unless their ban expires.
Any user can "Block" another user.
Block happens only between you two, this means you cannot see the messages from each other.
If one of the two users have blocked another user, none of them can see the messages of the other.
Blocks are individual between 2 users, they don't impact visibility for other users.