User communication concepts and naming

Messenger
1

Objective
Find consensus on naming and semantics of concepts we use to design and implement features related to user and chat management.

Request
Please comment on the labels and definitions outlined below. Any disagreement, concerns or comments about applying them. Biggest suggested changes are:

  • Move away from all use of the word [Contact] because of its ambiguous meaning.
  • Introduce an additional layer [Assigned user]
  • Introduce [Groups] that a user can be assigned to, [Trusted users] being a default group. This offers more flexibility going forward to manage privacy settings and is in line with a more clear distinction in the UI between [Blocked users] and [Trusted users] shortterm.

Note that labeling may or may not appear in the UI. This is a seperate conversation that can be more constructive one we have accurate and agreed on definitions.

Reason
In recent weeks inconsistent references to contacts and actions related to them surfaced. For example when [Removing] a [Contact], on a contact’s Profile screen, this contact would still be visible in the [Profile] > [Contact list] after restarting the app. https://github.com/status-im/status-react/issues/3585

Evidently this example occurs because a contact is never really added or removed. It’s merely shown and hidden. This requires taking into account dependencies such as when to show [Add to contacts] and generally increases the risk of inconsistency.

Explicit call for anyone with experience in documenting OWL and RDF schemas to contribute to add more structure to these concepts.

Thanks to @cammellos @yenda thanks for pre-discussing, please comment on any required changes.

Actors

User

Anyone you have exchanged a 1-to-1 message with.

Group

A labeled container that can hold a list of users that a given user considers the same, e.g. ‘Trusted users’.

  • A user can only assign others users to a single group.
  • ‘Trusted users’ is a default group
  • Sharing settings can be specified by group
  • Depending on the perspective, groups can be those that a user has been assigned to and those that the user as created and assigned others to.

Assigned user

Anyone you have assigned to a group, e.g. ‘Trusted users’

Assigner

  • The user who assigns or has assigned another user to a group (i.e. marks another user as a particular type of user).

Assignee

  • The user who is assigned to a group by another user (i.e. marked as a particular type of user).

Trusted user

A user who has been assigned to the group ‘Trusted users’.

  • a.k.a Contact

Trusted users

List of users who have been added to this default group.

  • a.k.a. Contacts

Mutual trusted users

Two users who have assigned oneanother to a user group ‘Trusted users’.

:::info
dd March 20, this includes chosen avatar and chosen name. Chosen name will be removed as part of Core Profile epic. Read more: Status.app
:::

Diagram of actors

Chats

1:1 chat

Collection of messages between 2 contacts who may or may not have assigned oneanother.

Public channel

Collection of messages that are assigned to a topic that anyone can tune into and fetch.

Group chat

Collection of messages between a set of max 10 individuals.

Actions by user and chat

View

View information about any user, where the visible information differs depending on if and what group this user has been assigned to.

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.

Accept connection request

For a user to grant a request to add another user to a default ‘Trusted contacts’ group.

Send message

Start a 1-to-1 chat by sending an initial message to another user. Users may or may not be assigned by eachother to a group.

Receive message

Receive an initial message from another user. The other user may or may not be assigned by eachother to a group.

Send transaction

Send transaction to another user. This action is disabled until the other user has assigned the user sending a transaction to a group that enables visibility of the wallet address.
==We currently still allow sending a transaction to any profile. Meaning we actively expose the wallet address. I’ve found that his has been and is a topic for debate and will address this in another discuss post.==

Send transaction request

Sending a transaction request, that includes ones wallet address, to another user.
==We currently only offer this option in a 1-to-1 chat regardless of whether someone is a trusted user. Is this a command we want to enable in public and group chats? For example to request donations==

Share profile link

View, Select and Copy/Send another user’s contact code to another person or entity inside or outside of Status.
==At the moment any user can Share another user’s profile link. Similar to Send transaction, this is topic for debate and I’ll address this in another discuss post==

Invite to group chat

Send a message to users inviting them to a group chat. Only users who receive an invite can join.

Delete

Remove the user from an assigned group. This only impacts the client of the assigner. The other user will no longer receive profile updates. Any profile information that has been shared will remain visible.

Block user

Removes all previously sent messages and no longer shows new messages sent by this user. The other user is not notified of being blocked, can continue to send messages and profile information that has been shared will remain visible to them.

The blocked user can create a new account, and send a message to the user who blocked them, given that they can identify them by their random name in chat or have access to their Contact code. The user who blocked them will see their message with a blue circle on their avatar, signifying them as a ‘new’ user.

1:1 Chats

Delete

Remove the chat from the chat list. Users of the chat are still able to [Send a message] and thereby add the chat back to the [Chat list].

Start

Send a message from another users profile or by adding their ENS name or contact code in Start chat.

Public channels

Delete

Stop listening to a topic. The user will no longer see this channel or its messages as the client will be unsubscribed from this channel and will no longer fetch messags for this topic.

Join

Start listening to the public channel’s topic. The channel will be added to the chat list.

Create

A channel is not ‘created’, rather a first message is sent, registering a topic it belongs to. From thereon out, the topic is included in the user’s Chat list as a channel and anyone fetching messages for this specific topic will see the topic in their chat list and can view and send messages belonging to the same topic.

We currently do not distinguish between sending a first message or joining an active chat.

Group chat

Create

Select contacts from the default assigned group ‘Trusted users’, label the group, and send an invitation.

Invite

Select Trusted users upon creation of the group or [Add members] on the group Profile view after a group has been created. This allows users to be added by existing members, who the creator has not added to a ‘Trusted users’ group.

Join

Accept an invitation to a group chat; this will inform members of the group that the user has joined.

Decline

Decline an invitation to a group chat; this will inform members of the group that the user has left.

View group info

Group info, including it’s members becomes available after joining a group and includes those who have joined the group.

Delete

Anyone can Delete a group chat from their chat list. The group chat will remain for others, showing that the user deleting the chat has left. A user can be re-invited upon which the group will reappear in the users list.

Clear history

Clear history removes all messages in any given chat.
==Any specifics on the purpose to be added: To avoid any association to conversations when phone is confiscated, save memory?==

6 Likes
2

@hester thanks for writing up this super comprehensive list. Personally it’s hard to comment on these without seeing them first hand in the application. However from just reading the description, and the logic behind the changes, they all seem reasonable.

What’s the best way to turn this from a discuss post into a living content strategy document that we can iterate on as we implement the language from the post?

2 Likes
3

Thanks for working your way through. In my mind this needs 2 follow-ups.

  1. A content strategy doc(as you raised) showing where these concepts surface in the UI. I can work on this; would look sort of like an abstract sitemap. Will take some time, time intensive + availability.
  2. A formal documentation of what these concepts are called in our codebase. Not my area of expertise. I made an attempt at at least a class diagram. Would love to hear from others what the best format is!

Utopia in my mind is an RDF schema that makes it easier for any contributor to find and consistently apply all classes, objects, properties and potential relations.

Use cases

  • a contributor wants to work on a bounty to add a Remove option to a profile screen and needs to see what this is called and what other areas might be affected as they use the same class and property (list of contacts in send transaction).
  • someone working on a ‘split the bill’ extension wants to offer this extension in a group chat and needs to know if everyone in the group will have eachother’s wallet address.
  • a contributor works on upgrading an existing feature, say splitting contact list into groups and looks for an efficient way to group users for a given user’s view.
3 Likes
4

Great initiative @hester ! Definitely would be very useful.

:fearful:

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.

2 Likes
5

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.

1 Like
6

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.

2 Likes
7

More accurate, agreed.

8

Makes sense, I will start something.

1 Like
9

For reference: ideally we have something like this: Thing - Schema.org Type for User, Group, Chat.

1 Like
10

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.

2 Likes
11

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:

2 Likes
12

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.

1 Like
13

This is what I have now: https://uxenzo.com/~status/userandchatmanagement_1.0.0.owl (cc @julien)
https://file.globalupload.io/FOUPbyA75N.mp4

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):

Consistency

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.

1 Like
14

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

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.

2 Likes
15

@hester I started some document here: Domain.md ¡ GitHub

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

And apologizes for the delay :cry:

2 Likes
16

References
Ethereum ontology work done by Consensys: https://ethon.consensys.net/

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 https://erc725alliance.org/

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

3 Likes
17

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
2 Likes
18

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.

2 Likes
19

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.
https://notes.status.im/9MyUbPFJS0C9jIBECL1o2A?both

1 Like
20

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.

Options

  • 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.

1 Like