You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Developers would like the ability to know which wallet address sent a message, not just the inbox_id or the installation_id.
Possible solutions
Every message is signed by an installation key. That installation key is part of an inbox, and it was added by a wallet. We store that relationship in the added_by_entity field on each member in the AssociationState. That is effectively which wallet address the sender used when they set up their app the first time.
Lazy loading
We could expose a way for anyone interested to look this up. They provide the inbox_id and the installation_id and we tell you which wallet address added them. The client would load the association state from the DB, find the member, and see who added them.
This is fine for an occasional lookup. There are a few problems.
Quite expensive to do this lookup. Wouldn't want to do it once for every message in a list, for example
The data we have on each message doesn't tell us at which sequence_id we should be looking up the AssociationState for the inbox. This lookup will fail if the installation has been revoked since the message was sent, since the installation is no longer present in the AssociationState
Preloading
As part of processing each message we figure out the sender wallet address before we save the row to the DB. We would need to add a sender_account_address field to the group_messages table. Maybe we do a migration to do this for all past messages as well. At the time we are processing the message we know what sequence_id to look for for each member, so we will always be able to find the account address.
This would be very fast at read-time, since we have paid the cost up front.
Association Table
Since one installation_id is only ever associated with one wallet address, we could create a lookup table that makes it fast to go from installation_public_key -> wallet_address. Technically it is possible to associate an installation key with multiple wallets, but in practice that should never happen.
Then we could join to that table when we are querying messages and get the value cheaply at read-time or offer a really fast API to do the lookup. Would need to figure out when to populate the table.
Potential Issues
I don't think this feature is a great idea in a lot of cases. Showing the sender's wallet address, instead of picking one consistently from the list of wallet addresses associated with the inbox, can be very confusing. Even in a 1:1 chat, a single user could show up as different addresses if they have multiple connected through different devices. Even more confusing in groups.
But it is useful context for devs, and I can see some times when you might want to know which wallet was the user using when they sent the message. For example, that's probably the wallet you should default to sending money to. I could see showing that info as a "press and hold" view when you want to see extra info about a message.
The text was updated successfully, but these errors were encountered:
Summary
Developers would like the ability to know which wallet address sent a message, not just the
inbox_id
or theinstallation_id
.Possible solutions
Every message is signed by an installation key. That installation key is part of an inbox, and it was added by a wallet. We store that relationship in the
added_by_entity
field on each member in theAssociationState
. That is effectively which wallet address the sender used when they set up their app the first time.Lazy loading
We could expose a way for anyone interested to look this up. They provide the
inbox_id
and theinstallation_id
and we tell you which wallet address added them. The client would load the association state from the DB, find the member, and see who added them.This is fine for an occasional lookup. There are a few problems.
sequence_id
we should be looking up theAssociationState
for the inbox. This lookup will fail if the installation has been revoked since the message was sent, since the installation is no longer present in theAssociationState
Preloading
As part of processing each message we figure out the sender wallet address before we save the row to the DB. We would need to add a
sender_account_address
field to thegroup_messages
table. Maybe we do a migration to do this for all past messages as well. At the time we are processing the message we know whatsequence_id
to look for for each member, so we will always be able to find the account address.This would be very fast at read-time, since we have paid the cost up front.
Association Table
Since one
installation_id
is only ever associated with one wallet address, we could create a lookup table that makes it fast to go frominstallation_public_key
->wallet_address
. Technically it is possible to associate an installation key with multiple wallets, but in practice that should never happen.Then we could join to that table when we are querying messages and get the value cheaply at read-time or offer a really fast API to do the lookup. Would need to figure out when to populate the table.
Potential Issues
I don't think this feature is a great idea in a lot of cases. Showing the sender's wallet address, instead of picking one consistently from the list of wallet addresses associated with the inbox, can be very confusing. Even in a 1:1 chat, a single user could show up as different addresses if they have multiple connected through different devices. Even more confusing in groups.
But it is useful context for devs, and I can see some times when you might want to know which wallet was the user using when they sent the message. For example, that's probably the wallet you should default to sending money to. I could see showing that info as a "press and hold" view when you want to see extra info about a message.
The text was updated successfully, but these errors were encountered: