[Standards] Feedback about stickers and more
Hi, It's just some feed back about my experience with xmpp alternative and a global reflexion, they are probably a little out of the scope who knows. Just let me knows what is out or not and what can be the best integration for that. Stickers : - stickers white or black with transparent background can be a problem with client theming (dark vs light) - stickers can be used for several channel/servers - provider should be able to configure (as server/client) with accept/ban list. for ie : xmpp.server.one : allow (provider.one/list1), disallow( provider.one/list2, provider.two) xmpp.server.two : allow (provider.one), disallow( provider.two) in a ideal world stickers list (and avatar pictures, and 3D avatar) are served by federated decentralised server and can be store client side with a way to store localy. Other stuff : - account need identity and a way to easily customize it t...@xmpp.server.one => one identity by server or per channel and a way to show or not vcard and other stuff. - a way to show (can be disactivate by profile) if a user is on same servers. - a way to add notes about a user or a channel (something see only by the user but syncable) for notes and vcard maybe the best is a way to send open it directly in an address book (probably already exist or something like mailto: ). J. OpenPGP_0x867BF14B0364AB34.asc Description: OpenPGP public key <> OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection
On 11/17/21 2:25 AM, Philipp Hancke wrote: Am 16.11.21 um 20:31 schrieb Daniel Gultsch: Hi, I’m trying to implement ICE Restarts with XEP-0371. The XEP states that ICE restarts can be detected by a changed ufrag and pwd attributes in the transport-info. However what I'm currently unclear about is how I can detect if the incoming transport-info is a request to restart ICE on its own or a response to an ICE restart we initiated. Or to put it into WebRTC terminology how do I know if a transport-info with changed ufrag/pwd is an Offer or an Answer. oh this does a fancy variant which doesn't map 1:1 to WebRTC sdp. Assume the following collision happening in parallel: initiator: restart, transport-info responder: restart, transport-info Upon receiving the messages, - the initiator consider the second message a response and maps it to an answer. - the responder will also consider it a response and map it to an answer. Both will then update their respective ufrag/pwd and be happy. It should actually work no matter what, leaving role conflict handling to ICE. Oddly https://jsfiddle.net/fippo/ytqmnsxh/5/ never changes the pair in Firefox but i'll go nag someone. I might know people. ;-) In general I would always initiate restarts from one side (e.g. the intiator), not both. Why bother with glare and conflicts when it is trivial to avoid... +1 /psa ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection
> - the initiator consider the second message a response and maps it to an > answer. > - the responder will also consider it a response and map it to an answer. > Hi Philipp, Why would it be considered as a response if there were no first? PS when are you going to return to xsf@ chat? :-) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection
Am 16.11.21 um 20:31 schrieb Daniel Gultsch: Hi, I’m trying to implement ICE Restarts with XEP-0371. The XEP states that ICE restarts can be detected by a changed ufrag and pwd attributes in the transport-info. However what I'm currently unclear about is how I can detect if the incoming transport-info is a request to restart ICE on its own or a response to an ICE restart we initiated. Or to put it into WebRTC terminology how do I know if a transport-info with changed ufrag/pwd is an Offer or an Answer. oh this does a fancy variant which doesn't map 1:1 to WebRTC sdp. Assume the following collision happening in parallel: initiator: restart, transport-info responder: restart, transport-info Upon receiving the messages, - the initiator consider the second message a response and maps it to an answer. - the responder will also consider it a response and map it to an answer. Both will then update their respective ufrag/pwd and be happy. It should actually work no matter what, leaving role conflict handling to ICE. Oddly https://jsfiddle.net/fippo/ytqmnsxh/5/ never changes the pair in Firefox but i'll go nag someone. In general I would always initiate restarts from one side (e.g. the intiator), not both. Why bother with glare and conflicts when it is trivial to avoid... ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
