Open tcpipuk opened 4 months ago
@tcpipuk when you get a chance, please sign off on your changes to allow the MSC to eventually be eligible for acceptance.
@tcpipuk when you get a chance, please sign off on your changes to allow the MSC to eventually be eligible for acceptance.
Sorry, did I do it right?
Looks great, thanks!
Seems we discuss here a key-value CRDT, as keys would need to be updated over time. Personally, I'm all in favor. With no regard be those events a part of a (messaging) Room or be in its own Profile Room (#1769) (which would be neat), we need a mechanism to get the latest key-value pairs.
Matrix Event Graph is isomorphic to Merkle-CRDT that powers OrbitDB (key-value DB is one of the supported CRDT). Taking an inspiration from how key-value CRDT works may be of help to spec it for those Servers wishing to opt-in.
I'm still talking to a number of projects about a possible user-interactive client implementation, but presently the mautrix-go library now supports this MSC, so the many projects relying on it will be able to read and publish profile fields: https://github.com/mautrix/go/pull/281
I am shortly going to add unstable and stable unstable_features
flags for the CS API to facilitate this, so client implementations know when they can use the "entire profile" PATCH
/PUT
endpoints.
conduwuit server-side partial implementation: https://github.com/girlbossceo/conduwuit/commit/f163ebf3bbaa9656bbf1d78355220e1d859b17c7#diff-6f6ce4833edde4b67f9f5c950adce5338f3e3a19b6d287c33ff4e9d290b94fa1
ruwuma (our ruma fork) partial implementation for conduwuit:
The partial implementation only supports GET/PUT/DELETE for just the us.cloke.msc4175.tz
field (MSC4175). More thought into supporting "generic" K-V fields is being done, but at least gets a basic implementation through the door that can be usable in any future clients that implement the timezone field (which seems likely soon 😇).
I think we can pop the needs-implementation label here too?
This has a couple different implementations for servers and SDKs, and at least one useful dependent MSC. So I think this is ready for a wider review from the SCT. I'm still unsure whether the length limitations are well designed (or over-engineered/confusing), but I'm hoping for input from the wider team if there are concerns.
@mscbot fcp merge
Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:
Concerns:
Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for information about what commands tagged team members can give me.
@mscbot concern Size limits section needs iteration
Rendered
Signed-off-by: Tom Foster tom@tcpip.uk
Known Implementations:
FCP tickyboxes