Open ggurdin opened 5 months ago
Could have user's own language info stored in matrix profile, and only use global store to access others' languages Check on setting of user profile (on login and on editing) and update the global info if it's different
Proposed Solution:
Open Questions:
Create a room that everyone in the server can join
I think this will mean that users will be able to see all other users on the server (i.e. they'll be able to search for all other users). I'm unsure if this is desirable or not.
Each user would also be able to dump a list of all other users on the server, which sounds not desirable.
To create or update this entry, each time a part of their profile is set or updated:
This sounds like you'll be using state events if you're "replacing" them. You would probably want an event type of chat.pangea.profile
and state key of the MXID. You'll want to ensure other users can't update each other's state events.
Unfortunately I don't think there's a way to easily limit who can set state events, m.room.member
has some special rules to do this, but other events don't.
The user leaves the room
If the user leaves the room I think they won't have access to up-to-date information of other users. It might work if the room is publicly joinable though, which maybe it has to be for anyone to just join. This has ramifications if you ever turn on federation though.
Is the main piece of information that this cares about the user's language or is there additional information that should be kept private?
Yes, the main piece of information we want to store right now is the users' languages (and countries), which we want to be available to other users so they can search of others by the languages they know / are learning. We do have information that needs to be kept private, like users' dates of birth, but that data would not be placed in this room.
the main piece of information we want to store right now is the users' languages (and countries), which we want to be available to other users so they can search of others by the languages they know / are learning.
Right. I think storing it all in the room has the downsides I mentioned above, but I don't have a much better solution at the moment. There's a couple of things which might work, but I need to investigate first.
We're going to take out plans for the 'find a conversation partner' feature in favor of a 'find a learning community' feature.
Reasoning: Users of other language exchanges often complain about harassment, trust, issues, etc. Communities will have admin who can help alleviate this. User of other language exchanges also have issues finding people with whom they can have meaningful conversations. Joining communities and participating in group chats should let people interact more indirectly and find common interests, etc.
Score leaderboards can also be done within spaces.
Architecture proposal based on this design change:
1) Each user in a space will have an event (type="chat.pangea.profile", state_key=user_id) in that space which contains their profile information. 2) This event is set or updated at the following times:
The user's matrix account data will also duplicate this account data, and should be updated each time the global profile is updated. This is to make it more efficient to get the user's language settings, so they do not have to leave and join the room when their language info is read. It unfortunately duplicates this information (in their profile and in each room) but this seems to be necessary given other constraints.
The bot can access user languages directly from the database.
With this set of changes, it seems to unnecessary to do a public room for all users.
@clokep Is user_id the same as MXID? If not, what is MXID?
Each user in a space will have an event (type="chat.pangea.profile", state_key=user_id) in that space which contains their profile information.
If you're going to have a space per language, would being joined to the space be enough "information" that the user is interested in that language?
Is user_id the same as MXID? If not, what is MXID?
Usually I refer to "user_id" as the local part of the "MXID" (e.g. user_id = clokep, MXID == Matrix ID = @clokep:matrix.org). This might not be a universal definition though! They're usually interchangeable.
Someone wrote a new MSC to support custom fields in profiles which could maybe be used for this. It isn't yet supported in Synapse (and would be experimental). You wouldn't be able to search users for these fields though, so probably still wouldn't accomplish what you need.
It'd be overjoyed if this MSC built on MSC4133 to add extra features like search! ❤️
Hi @tcpipuk ! Cool - that's certainly a possibility!
I'm not sure if we'd necessarily need to write an MSC for it, they could just be namespaced properties (chat.pangea.languages
) or something like that.
@clokep I want to confirm my understanding on the current state of things.
A user can currently save and access arbitrary key value pairs to their own Matrix profile information. We're doing this now. It seems to work. It'd be great to know of any known edge cases with this functionality.
Is this information accessible by other Matrix users. If not, is this what the linked MSC seeks to add?
We're doing this now. It seems to work. It'd be great to know of any known edge cases with this functionality.
I don't see how this could work, the endpoints don't exist to store arbitrary information in a user's profile. Are you storing arbitrary information in a user's account data? Account data is not accessible to other users, while a profile is.
My bad! I did not know they were two separate endpoints. We know now. We were using the account data endpoint.
@clokep What are our options for getting searchable user profiles for Pangea Chat in the near future? We desperately need this functionality!
@clokep What are our options for getting searchable user profiles for Pangea Chat in the near future? We desperately need this functionality!
Even with MSC4133 we wouldn't get searchable user profiles, although I think that would be a fairly simple MSC on top of it. I partially implemented MSC4133 in Synapse (unrelated to Pangea Chat), but ran into a couple of questions that I need to talk to the Synapse team about.
I'm still a bit confused on the user experience though, are you hoping that:
@clokep Oh that's awesome! So if that's merged into Synapse, we can update and use it? Exciting!
Searchable user profiles would be ideal but just being able to query with mxid would satisfy the most immediate needs.
Yup, data we want to store includes languages and also summary learning analytics like a language proficiency level. We want more robust public user profile as the related MSC talks about. Ideally, users can search for conversation partners via these fields.
Oh that's awesome! So if that's merged into Synapse, we can update and use it? Exciting!
Yes, we'll probably need to wait for it to get released if we don't want to go through a huge hassle.
It's up now: https://github.com/element-hq/synapse/pull/17488
We want a json of user profile information accessible to everyone in the app. A user, and only that user, should be able to set and edit their information.
Features to use this
Open questions:
Resource considerations