You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3D avatar / thumbnail should be saved in m.world.profile room state event
So we can assume it's planned to be state events for now as a primary data point in profile type rooms. My only issue with this is interoperability:
one needs to do extra steps to download their backed up model/sprite, as well as to see related thumbnail, from any other client;
profile room will just look empty or have events of which only Third Room client can make sense.
I propose such binary data to be sent as attachment instead of room state event.
The text was updated successfully, but these errors were encountered:
vintprox
changed the title
Send avatar's model and thumbnail as attachments to profile room
Profile interop: Send avatar's model and thumbnail as attachments to profile room
Sep 30, 2022
vintprox
changed the title
Profile interop: Send avatar's model and thumbnail as attachments to profile room
Profile interop: Send avatar and thumbnail as attachments
Sep 30, 2022
If the problem is how to pack everything together under one avatar, there is such thing as relations. I presume we can take attachment and put into it a relation to original event that describes single avatar (which in return can remain room state event, or even better - a message with HTML/text description that other clients can simply show above those attachments).
If we send m.world.profile as message and attachments in relates to original message we will not have a direct way to look profile either we have to backfill timeline until we find relevant event or we need to remember the event id to access it via /context api.
#70 mentions:
So we can assume it's planned to be state events for now as a primary data point in
profile
type rooms. My only issue with this is interoperability:profile
room will just look empty or have events of which only Third Room client can make sense.I propose such binary data to be sent as attachment instead of room state event.
The text was updated successfully, but these errors were encountered: