In reply to @emma:conduit.rory.gay
my issue also involves keeping that data around in a historical context, though, which i dont see a solution for besides using more PDUs

In reply to @tom:doctoruwu.uk
I suspect clients will not immediately aggressively push out hardcoded fields because the names of the fields are probably not going to be the same between clients - the idea is to get this basic functionality in place so other people in the community can start thinking about what they want to do with this feature they now have, and then they can raise an MSC to solidify specific behaviours (e.g. per-room fields, logging changes, or specifying the naming convention of certain fields across all clients)

In reply to @travis:t2l.io
I haven't looked at the MSC yet, but I would generally expect the fields to be shared in membership events like the current profile fields.

In reply to @travis:t2l.io
I haven't looked at the MSC yet, but I would generally expect the fields to be shared in membership events like the current profile fields.

In reply to @cat:feline.support
i can get a pretty penny that the clients will very quickly unify naming of popular fields as the client userbases will write annoyed messages or worse at each other if it doesnt.

In reply to @tom:doctoruwu.uk
That is not the suggested behaviour, but I'll let you have a read first - Tulir and Patrick have commented quite a bit, and I've been updating the MSC in response 🙂

In reply to @tom:doctoruwu.uk
I suspect clients will not immediately aggressively push out hardcoded fields because the names of the fields are probably not going to be the same between clients - the idea is to get this basic functionality in place so other people in the community can start thinking about what they want to do with this feature they now have, and then they can raise an MSC to solidify specific behaviours (e.g. per-room fields, logging changes, or specifying the naming convention of certain fields across all clients)

In reply to @cat:feline.support
i can bet a pretty penny that the clients will very quickly unify naming of popular fields as the client userbases will write annoyed messages or worse at each other if it doesnt.

In reply to @travis:t2l.io
again, these sorts of comments only serve to demoralize. Let's not place bets on MSCs, please.

In reply to @travis:t2l.io
The comment also introduces a concern for the MSC to consider: we generally prefer highly prescriptive behaviour, and so may need to work out what a registry or official set of common fields look like. We don't want people to follow one client's behaviour because that's who did it first.

In reply to @tom:doctoruwu.uk
My expectation was that users would be entering their own freetext fields in this "extended" attribute, but that people would then go "Wow, it's really useful being able to specify X and I'd like to do it at the room level, so let's promote this one specific field outside the "extended" object with an MSC"

MSC3755: Member pronouns by @Gnuxie

In reply to @emma:conduit.rory.gay
Tom, I feel like it might be worth bringing up MSC 3755 in this case, given that's the kind of usecase it seems you're trying to address, right?

In reply to @travis:t2l.io
(this would be great context to add to the MSC if it's not already there, and is a pretty strong argument for not putting fields at the top level by default)

It currently says this, should I add more?

This proposal does not seek to enforce the content or usage of these key:value pairs, but rather add a framework to for users to have extra data that can be further clarified and extended in the future as community usage of these fields grows.

In reply to @travis:t2l.io
(this would be great context to add to the MSC if it's not already there, and is a pretty strong argument for not putting fields at the top level by default)

It currently says this, should I add more?

This proposal does not seek to enforce the content or usage of these key:value pairs, but rather add a framework to for users to have extra data that can be further clarified and extended in the future as community usage of these fields grows.

I guess I could be more clear about specific use cases!