Deleting a message using a client token deletes it for all clients – inconsistent model

[Equilibrier]

Problem
Deleting a message using a specific client token causes the message to disappear for all clients, regardless of when they connected or which token was used. This invalidates the purpose of client-level scoping and introduces confusion about visibility rules.

Steps to reproduce

1. Send a message using an app (AppToken A) and a client token T1.
2. Connect from another device or browser (new client, token T2).
3. Delete the message using token T2.
4. Refresh browser from T1 — the message is gone.

Expected behavior
If client tokens define scoped message views, deletion should be isolated to the issuing client only.
Alternatively, if messages are globally visible per app, then deletion should be bound to the app identity — not the client — and the concept of “client” should be dropped or clarified.

Suggested resolution
The current model mixes concepts without clear enforcement:

• If all clients see the same messages, there is no benefit in having message deletion scoped to client tokens.
• Replace deletion logic to be based on the app identity, i.e. deleting globally per app.
• Either remove the "client" concept entirely or repurpose it for filtering logic (e.g. per-client view settings), not for visibility or ownership.

This also opens the door for features like server-side retention (e.g. keep only last N messages) and unique messages, managed cleanly per app.

[eternal-flame-AD]

I am not sure which behavior do you think you want? This seems like the same as #807 just a different take on what the desired behavior should be?

Please close one of them and consolidate your opinions. Thanks

[eternal-flame-AD]

FTR, what I understand "client" simply means a device used to access the message. Be it a computer, a smartphone, an IoT device, or simply an application on your server reacting to messages in pre-programmed ways.

I don't really think deletion should be scoped to clients, so if we are going with one of your suggestions I would go with #807. The logic described here seems very confusing to me.

[Equilibrier]

Thanks for the reply — I want to clarify a few things since I think there’s some misunderstanding here.

"I don't really think deletion should be scoped to clients"

I agree — I’m not necessarily saying it should be scoped that way. I was just trying to reverse-engineer the intent behind introducing "client" tokens in the first place. If they don’t affect visibility or message lifecycle (like deletion), then I’m not sure what their functional purpose is. Why have them instead of sticking with app tokens only?

What I’m reporting is a mismatch:

Deletion only works when using a client token.

But the effect of the deletion is global — it affects all clients under the same app.
That seems contradictory. If deletion is global, why is the client token even required to perform it?

"This seems like the same as #807"

#807 is about custom WebSocket implementations which are not handle-ing deletion events made by an API, from any client app. That’s different from what I’m reporting in current issue: in here, I’m saying that even with correct tokens and logic, deletion behavior is inconsistent or misleading — you have to use a client token, but the deletion affects everyone. So these are not the same bug.

To summarize:

If messages are global per app, deletion should be app-scoped and based on the app token.
If deletion only works through a client token, then logically the deletion should be per-client.
If neither is enforced clearly, we end up in this weird middle ground that breaks expectations.

I’m happy to adapt to whatever model you want — but it should be clearly defined and consistent. Right now, it feels like a mix of ideas that don't quite add up.

Can you clarify what the intended behavior is, and what role "client" is supposed to play in the current model? As I'm seeing, it has no real functional purpose, almost like the users as well - another discussion where I don't have enough experimental data on, but feel free to touch that topic as well, as I'm interested a little bit about that one as well.

[jmattheis]

Why have them instead of sticking with app tokens only?

App tokens are only able to send messages to this specific application. This allows it to be used in untrusted environments where you don't want a malicious actor to delete anything. E.g. you send messages including the source ip for successful ssh logins. In this case you don't want some malicious user to delete the ssh login messages.

Client tokens are a way for clients to access the api without storing the username / password. You could see it as general access token which has mostly the same permissions as accessing the api with basic auth.

You could see both client and application tokens as access tokens with different permissions that manage resources of a user.