User communication concepts and naming



Great initiative @hester ! Definitely would be very useful.


For various reasons the codebase is probably a mix of half implemented older versions of those concepts. And defunct ones.
We should probably align to what the content strategy doc will define. Similarly to what is being done for design components.


Absolutely. That’s the idea, just not really sure where to start. Is there a way to reference to the older versions and half implemented concepts? A start could be a spread sheet with at least a mapping of these labels and what they are called now in the codebase.


sweet, thanks @hester for compiling this :pray: I don’t see anything I’d disagree with there, maybe other than the use of ‘Delete’ when it comes to Public and Group chats. It’s not really the case, the message history and everyone participating is still there, so you’re only leaving the chat and removing it from your list. By ‘Delete’ I’d rather assume you’re actually deleting it entirely along with content and I’d feel hesitant when presented with such action, if it wouldn’t screw things up for other chat members. I’d suggest ‘Leave chat’ / ‘Leave group’ as alternative.


More accurate, agreed.


Makes sense, I will start something.


For reference: ideally we have something like this: for User, Group, Chat.


Thanks very much for this, @hester! It’s a great time to get a handle on our terminology and make sure that it accurately reflect what’s happening.

I have one thought on the terminology itself…

Most of these are intuitive to me, although the switch to assigning from adding contacts will be interesting, because of the novelty. Did you consider add to group as an alternative?

From my understanding, the main problem is that we have an unusual definition of contacts—they are more like trusted users.

I ask because there’s one place I might get lost, as a user, in the actions you take to add or be added:

Assign to group (at the moment Add to Contacts)

Assigning another user to a group, e.g. ‘Trusted users’

Send connection request

Request by a user to be assigned to the default ‘Trusted users’ group.

  • This may or may not require the requester to add this user to the default ‘Trusted contacts’ group themselves.

The use of the term connection request is disparate enough from assign to group that I might not realize it is the same action, with the assignee initiating. I do like how concise it is, but maybe we could find a way to use more similar language.

The one suggestion that makes sense in my mind off the bat works off the familiar verbiage of adding someone, e.g. Add to group and Request to be added.

As long as we clarify that Trusted users has different implications than Contacts, I think we still solve that confusion.


That’s a great alternative!

These labels are definitely open to change. Most critical to me is mapping where we use the labels so that we can change them consistently and indeed, see how any change would impact for example a contact request flow.

The idea would be that in the system model, we completely get rid of Contacts. There would only be users that you assign/add to a Group and that group has a Name.

Coincidentally, the group might even have the name Trusted contacts in the UI. Semantically that doesn’t mean you add them as a trusted contact, you add them to a group that happens to have this name.

Working on a model to show the relationship between the above labels and definitions. Can’t believe part of me enjoys doing that :star_struck::joy_cat:


Working on a model to show the relationship between the above labels and definitions. Can’t believe part of me enjoys doing that :star_struck::joy_cat:

Glad somebody does. :stuck_out_tongue:

Coincidentally, the group might even have the name Trusted contacts in the UI. Semantically that doesn’t mean you add them as a trusted contact, you add them to a group that happens to have this name.

Makes sense!

If we’re able to map out the use of these various terms across the product, that will also make translation easier.

Honestly, looking at some of the product copy within lokalise has me thinking that communication concepts are just the tip of the iceberg.

This is a great start. Let me know how I can help moving forward. On how to document this information, it would definitely make sense to have a schema (or even a table?) included in our documentation—which Jonny is in talks of having a third party partner help with.


This is what I have now: (cc @julien)

I’m definitely down a Semantic web rabbit hole or better said, caught in the web:)

Not ready to give up yet.:face_with_monocle: Benefits of documenting our concepts in an OWL (Turtle in this case):


Predictable behavior and planning of upgrade paths; we could query where in the application changes will occur when we decide to change the language in one context.

Shared language

It’s a source of truth. Anyone can edit the OWL, but what is in the OWL is the exact meaning of for example a Contact or Adding someone.

Interoperability between applications

We can even include things that mean the same thing. For example ‘wallet address’ is the same as ‘public key’ and use annotations to indicate what applications in the space use what language. Other applications could request a Wallet address whereas we know to provide the public key.

Interoperability across applications

If anyone were to build a messenger following this language you could export your contacts and bring them along to your new preferred messenger, say you want to switch to Mastodon or a different build of Status. This is powerful considering that a significant adoption barrier currently is that you have all your friends on Facebook.


Excellent work, Hester.

Agree that calling contacts is confusing. I agree with the concept of groups.

I am happy to contribute with my thoughts on this.
I think we should consider “Contacts” as “a set of contact”, but contacts themselves are stored in these groups with different permission settings. I think your realization of the meaning is very good already.

Default groups

I think the ideas behind default groups could be as:

  • known: is not trusted, but is not untrusted either.
  • “trusted”; users which you agree sharing additional information (wallet, picture, ens-name, volatile name)
  • “blocked” : specifically untrusted, ignore messages, dont share data, etc.

This is really useful for choosing who you want to share certain information with, and having this clear to users is fundamental.


Extendability is also important to take into consideration, in the example of a “gps tracking” dapp, which you want your close relatives to know your exact location everytime they request it.
This groups could be passed to the dapp to give allowance of all participants in some functionality to their contacts.
Other example would be a personal photobook dapp, where people share moments of their life with friends, where each post could use a different group to share the post with.

It’s important to provide this API for Dapps, because social networks relay on contacts, and Social Networks Dapps would need a contact list, and Status could provide this list (instead of each dapp have thir own list)

The Chat App could be using this API to grab contacts info and other user data, so it could be a detachable from codebase.


@hester I started some document here:

Let me know if that’s the type of thing you had in mind!

And apologizes for the delay :cry:


Ethereum ontology work done by Consensys:

Updates 1.0.1

Next steps

  • Include the tags @julien has collected from the codebase
  • Add mappings to tags that cannot be updated (e.g. :Contact/added due to compatibility)
  • Include DApps and Extensions
  • Learn more about JSON-LD definitions
  • Check with @ricardo3 for any related definitions on users and identity in

And many thanks to @petty for discussions on the best approach on concepts, modeling and collaboration!


I’m trying to find a way to reconcile the graet work currently being done by @adam and the protocol team (@oskarth and @decanus) on the Status spec. These two things (rdf semantic web stuff) with their protocol spec should go hand and hand and complement each other… one explaining exactly how things are done, and the other linking them together in a graph.

With those two things, you can:

  • reason about how to implement something exactly
  • figure out where it fits into the whole picture
  • reason about the effects of changes
  • other stuff i’m not thinking of right now


I am excited to start building apps and enhancing UX through Identity contract.

Self Sovereign Identity makes better many sort of features, such as:

  • key migration;
  • subscriptions;
  • public profiles;
  • KYC claims;
  • social account recovery;
  • multi sign;
  • multi key;
  • and more to be invented.

It also makes possible different types of DApps, which the rules are defined as a Identity Extension.
For example, a DEX which don’t uses a centralized contract to handle trades, instead the DApp uses a ABI endpoint in Identities which contains the rules for trading. The Identities would broadcast their trades in whisper. This would make possible to users to open trades without making the transfer to a DEX - useful for keeping voting influence in liquid democracy and for decentralizing legal responsibility.
I proposed this type of DApp architecture for Teller Network, therefore the Identities trading would be the only actors responsible by the in chain and real world actions.

My research on Gas Abstraction (a type of identity extension) lead to a possible path where we can use these Self Sovereign Identity with very low UX burden.
Through using CREATE2 OPCode, Identity can be safely used to store assets before they are deployed, and having it’s deploy payed by any gas relayer which are willing to claim the first meta transaction.

The current code of Identity it’s featured with all needed for this happen. However the ERC725 changed in the meanwhile.


My initial reaction is to strongly discourage the use of StatusAccount as a term, I’m afraid I don’t quite understand the reason to do so, over the weekend I had made some clarification to terms to the upcoming multiaccount call.


Happy to keep iterating on that. I’m not set on using Account. Came back to it yesterday as I haven’t found an alternative to refer to the ‘thing’ that the user creates initially. I also haven’t found a way to circumvent naming of this ‘thing’ in the UI.


  • StatusAccount to communicate it is the core, whilst in the OWL indicating it as equivalent to Master Keypair (my current direction)
  • Master Keypair.
  • alternative?

1Password and Lastpass both use the concept of primary layer Account, with Vaults next to that.

Will update here with copy suggestions for onboarding screens.


StatusAccount indeed is not really explainful, and actually those accounts are all user-owned, they are standard ethereum identities.

What you could have is “Status-compatible Public Profile” or other derivates, however the Account which controls this public profile is not related to Status. StatusIM only provide the interface to certain standards.


Our main privacy concern is that we use the wallet key to directly derive the chat identity as the wallet public key.
As feature and privacy concern we have that any chat identity can derive the wallet of user.

We had the discussion of having one identity per dapp, this might be done with Identity, which new dapps could have its own key to access funds from an Self Sovereign Identity. This still don’t fixes privacy, as we always need to fund the key from somewhere.

For Dapps which don’t require inchain transactions, but requires an Identity, it would be possible to add the dapp-specific public key hashed in keccak256 listed in the Self Sovereign Identity.
As example, Status Chat could read a message signed from a key, and this message could contain in its payload the user-public-identity, where clients could query in the smart contract to check if key is listed as a key. For Messages that pay the network, this key could be allowed to sign payments.

Currently most of in-chain actions are “pull based”, users pull the transaction to queue and incentivize the mining by posting a gas fee. With Identity contract it’s possible to have a “push based”, where transactions are authorized in a smart contract action key, which could control subscription rules.
Instead of using a regular external owned account as key, the User would set an smart contract as key, which would contain the rules for the subscription, where subscriber could push funds based on those rules.


We also need to define a standard way of displaying Identities. There is a proposal of standard here

We can propose our own standard, but what is important is that in all Status related stuff this is coherent. I’m doing some experiments in how to display addresses data in a more human way, such as using colors.

This should build an “Identity Input” component, which could support both public key or address, but might require public key in some cases (Contact Code needs full public key, transactions only need address).
Within this Identity Input we can also support universally the ENS resolver, and public avatars, such as suggested in ERC 928.
Identity Component would intelligently query the Identity for needed information regarding the it’s value, where if it’s a contract, it could support ERC780, former ERC725 and ERC735 ABI to badge with known claims/signers, e.g. Status GMBH badge/unbadge addresses to get a “support team”, “core dev”, “etc” badges to some identities which are “certified as trustful” to the badge they hold.