Dendrite sends read receipts regardless of user preference

[necropola]

Background information

• dendrite-0.13.4+317b101
• postgresql-15.4
• Running native (no docker) on ArchLinux with nginx as SSL proxy
• go-1.21.4
• element-web-v1.11.51

Description

• Read Receipts are sent even when disabled in element-web User Preferences/Presence.
• Disabling inbound/outbound presence in dendrite config has no effect on receiving/sending receipts. (I have both disabled on my dendrite server.)
• I'm getting the Read Receipts from dendrite on another user/server (synapse with same element-web version)

Steps to reproduce

• Disable sending Read Receipts in element-web client with dendrite HS and read a message the other (synapse) user posted to a chat room
• Check on the other user (synapse) with show read receipts from other users enabled that they are still getting read receipts from dendrite,
• Doing the same from the other (synapse) user works, i. e. read receipts are not sent when disabled by user preference.

Basically synapse honors this (element) user preference and dendrite ignores it.

[S7evinK]

Imo, not a Dendrite issue, more Element Web..
The client knows what to send and what not..

We can't check everything a random client sends us.

[necropola]

Does the client (element-web) talk to other servers or is it the homeserver (dendrite, synapse, ...)? I thought it's the latter. And somehow synapse knows how to handle the user preference. I think we should, check what's in the matrix protocol specs.

I think, it's about whether dendrite supports MSC2285 or not, but it apparently got a checkmark for supporting it: #3222

Note, that I am only assuming that element-web (correctly) uses hidden/private read receipts when the user disables the option to send read receipts to other users. I neither know for sure nor am I knowledgable enough (yet), to figure out what's going on exactly.

[S7evinK]

Right, Element Web does indeed not use m.read.private (Spec) as the receiptType since we don't announce support for Matrix 1.4.

If you really want this now, you can patch

dendrite/clientapi/routing/routing.go

Lines 132 to 153 in fd11e65

	publicAPIMux.Handle("/versions",
	httputil.MakeExternalAPI("versions", func(req *http.Request) util.JSONResponse {
	return util.JSONResponse{
	Code: http.StatusOK,
	JSON: struct {
	Versions []string `json:"versions"`
	UnstableFeatures map[string]bool `json:"unstable_features"`
	}{Versions: []string{
	"r0.0.1",
	"r0.1.0",
	"r0.2.0",
	"r0.3.0",
	"r0.4.0",
	"r0.5.0",
	"r0.6.1",
	"v1.0",
	"v1.1",
	"v1.2",
	}, UnstableFeatures: unstableFeatures},
	}
	}),
	).Methods(http.MethodGet, http.MethodOptions)

to include 1.4

[necropola]

Let's see, if I understand this correctly:

• Clients when talking to Servers may only use features/messages from a Matrix Protocol Version the Server has announced to support.
• Servers may only announce support for a Matrix Protocol Version, if they fully support ALL features/messages of it.
• Even though dendrite already supports the required feature/message (m.read.private), the clients (element) is not supposed to use/send it, because dendrite did not announce (full) support for the Matrix Protocol Version (v1.4) it belongs to.
• I could (wrongly) claim full support for v1.4 by patching the dendrite sources (that's easy), but this would make clients assume my dendrite homeserver fully supports ALL v1.4 features, e. g. Threads (m.thread) as per MSC3440: Threading via m.thread relation matrix-spec-proposals#3440, MSC3816: Clarify Thread Participation matrix-spec-proposals#3816, MSC3856: Threads List API matrix-spec-proposals#3856, and MSC3715: Add a pagination direction parameter to /relations matrix-spec-proposals#3715, too.

This makes it even harder for dendrite (server) developers to keep up with possible feature creep introduced by other (client and server) developers and gives a lot of power to the people deciding what goes in to a Matrix Protocol Version.

[S7evinK]

Exactly.

As you've seen, I've created several issues regarding support for specific versions. Thing is, we already claim to have support for 1.1 and 1.2, which in reality we don't.

[necropola]

Announcing support for v1.4 (and v1.3) by patching my dendrite sources does indeed fix this issue. Though this isn't of course a proper fix. What would be the best way to go forward? Add all features (MSCS) to dendrite to fully support the matrix protocol up to version v1.x with x being what? (synapse-1.98.0 has just announced support for v1.7, v1.8, and v1.9)

• My golang skills are quite rusty and have never been particularly good.
• I'm kinda worried about the future of the non-mainstream matrix clients and servers. Seeing how element and synapse are pullling ahead.
• How does/will the new license and repository impact dendrite? (https://github.com/matrix-org/dendrite/discussions/3281l)
• matrix-org/synapse has now been forked to element-hq/synapse and has then been archived at its original place.

[spaetz]

What would be the best way to go forward?

Indeed, the only way right now is to implement the missing features, to support matrix up to 1.4. there are meta issues for each version.

There are ideas floating to announce feature support instead of version support, but that is not what the spec says right now.