thilo.molitorhi everyone. I wanted to make some editorial changes to my pull request, regarding the xml schema in xep 0353,but I'm not sure if I understand xml schema sufficiently enough to do the right thing.
thilo.molitorthe reason element is copied over from the main jingle xep, but I want to reference the jingle schema and use it rather than copying the parts needed over to xep 0353. Is my commit correct or did I make some xml schema mistakes?
Sevehas left
Alexhas left
debaclehas left
me4youhas left
me4youhas joined
florettahas joined
djorzhas left
alacerhas left
alacerhas joined
me4youhas left
me4youhas joined
Conspicuous Obscurityhas left
adiaholichas joined
Steve Killehas left
Steve Killehas joined
sonnyhas left
sonnyhas joined
Conspicuous Obscurityhas joined
florettahas left
florettahas joined
me4youhas left
me4youhas joined
Yagizahas joined
me4youhas left
me4youhas joined
kyemxdenhas left
kyemxdenhas joined
BASSGODhas left
marc0shas left
BASSGODhas joined
marc0shas joined
adiaholichas left
adiaholichas joined
chronosx88has left
chronosx88has joined
chronosx88has left
adiaholichas left
adiaholichas joined
sonnyhas left
sonnyhas joined
Conspicuous Obscurityhas left
Sevehas joined
florettahas left
florettahas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
jgarthas left
jgarthas joined
wurstsalathas joined
andyhas joined
adiaholichas left
Tobiashas joined
adiaholichas joined
kyemxdenhas left
Conspicuous Obscurityhas joined
julianhas left
adiaholichas left
adiaholichas joined
florettahas left
ti_gj06has joined
adiaholichas left
andyhas left
adiaholichas joined
lorddavidiiihas joined
florettahas joined
emushas joined
neshtaxmpphas left
u70jfzo5eyeb468b9ohas left
Conspicuous Obscurityhas left
adiaholichas left
adiaholichas joined
restive_monkhas left
chronosx88has joined
millesimushas joined
emusjonas’
reimarhas left
adiaholichas left
adiaholichas joined
restive_monkhas joined
Conspicuous Obscurityhas joined
msavoritiashas joined
andyhas joined
restive_monkhas left
Conspicuous Obscurityhas left
adiaholichas left
me4youhas left
huhnhas left
huhnhas joined
huhnhas left
adiaholichas joined
rafasaurushas left
andyhas left
ti_gj06has left
Menelhas joined
me4youhas joined
Titihas joined
rafasaurushas joined
me4youhas left
adiaholichas left
me4youhas joined
Yagizahas left
adiaholichas joined
andyhas joined
larmahas left
larmahas joined
nycohas left
me4youhas left
me4youhas joined
jonas’I don't speak XML schema very well myself, but I'll take a look when I look at the PR
andyhas left
adiaholichas left
me4youhas left
andyhas joined
adiaholichas joined
mdoschhas left
Mikaelahas joined
mdoschhas joined
Conspicuous Obscurityhas joined
restive_monkhas joined
Thilo Molitorhas left
Thilo Molitorhas joined
pasdesushihas joined
jgarthas left
tykaynhas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Mikaelahas left
lskdjfhas joined
me4youhas joined
lorddavidiiihas left
nycohas joined
lskdjfhas left
lskdjfhas joined
lskdjfhas left
Alexhas joined
nicolahas joined
nicolahas left
nicolahas joined
sonnyhas left
mjkhas joined
nicolahas left
emushas left
debaclehas joined
stphas left
atomicwatchhas joined
stphas joined
arnehas left
arnehas joined
arnehas left
arnehas joined
arnehas left
arnehas joined
arnehas left
arnehas joined
stphas left
Yagizahas joined
sonnyhas joined
adiaholichas left
arnehas left
arnehas joined
arnehas left
arnehas joined
adiaholichas joined
arnehas left
arnehas joined
alacerhas left
millesimushas left
arnehas left
arnehas joined
alacerhas joined
millesimushas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
Menelhas left
flowdue the recent "superseed" changes to the XEPs, I became aware that we are probably missing a nice disclaimer that this XEP is superseeded by another in the XEP header (you know, just like RFCs / I-Ds have such a thing)
COM8has joined
flowhmm it's probably not so hard to xslt such a thing™
COM8has left
ti_gj06has joined
huhnhas joined
harry837374884has joined
COM8has joined
COM8has left
COM8has joined
adiaholichas left
Menelhas joined
COM8has left
Conspicuous Obscurityhas left
wurstsalathas left
wurstsalathas joined
stphas joined
adiaholichas joined
debaclehas left
Yagizahas left
Yagizahas joined
larma> https://xmpp.org/extensions/xep-0403.html#usecase-iq-relay
> The MIX channel will modify the JIDs in the outgoing message, so that the 'to' is the full JID of the recipient
Last time I checked, MIX room members are registered by their bare jid not full jid. How is this supposed to work?
larma> https://xmpp.org/extensions/xep-0403.html#usecase-vcard
> The MIX service will then address the vCard request to the user's server (using bare JID)
So the MIX service will need to have special handling for vCard and not just handle it like every IQ?
larmaI kinda get the feeling that MIX replicates all the dirty quirks we already have in MUC implementations today rather than fixing them properly...
adiaholichas left
Menelhas left
adiaholichas joined
debaclehas joined
mjkhas left
restive_monkhas left
flowlarma, not that I know the answer, but is the MIX server maybe subscribed to the user's presence?
arcxihas left
mjkhas joined
larmaAnd what happens when you have two devices online?
flowmagic :)
larma> MIX replicates all the dirty quirks we already have in MUC
flowbut yes, that seems to be fragile and maybe it should be clarified that it only works under certain conditions
larmaMaybe just accept that IQs are not meant for (semi-)anonymous groups?
larmaand vCards
flowI can only assume that the authors intention was to allow for certain established use-cases
Yagizahas left
larmaI mean... vCards are literally about sharing your personal details which is the opposite to staying anonymous...
mjkB- but muh muc avatar!
flowlarma, I am curious what you have in mind what "fixing them properly" could mean here
Sevehas left
Sevehas joined
arcxihas joined
adiaholichas left
larmaEither allow the sender to decide which resource/device the IQ should be sent to (or that it should go to the bare jid) or just don't do IQs. If you want vCards or avatars in semi-anonymous groups, allow users (optionally and per room) to upload those to the group server.
nuronhas left
pjnhas left
mjk> If you want vCards or avatars in semi-anonymous groups, allow users (optionally and per room) to upload those to the group server.
This sounds like it'd also fix the one-vcard-many-rooms problem (having different avatars & stuff in different rooms). Awesome
arcxihas left
ti_gj06has left
flowyep, I think that would be an improvement, but also complicates the protocol. not sure if it's worth it, I currently tend to be happy with IQs not working in semi-anonymous rooms
flowhowever, people want avatars everywhere, even in semi-anonymous rooms where they could be a way to de-anonymize them…
larmaflow, that's probably because most people don't care if they are semi-anonymous in the room
mjkYea, avatar is like an extension of nickname
larmaI mean, you are also writing on public mailing lists without anonymity.
Samhas left
uhoreghas left
homebeachhas left
Rixon 👁🗨has left
Matthewhas left
Half-Shothas left
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
mjkMatrix seems to make that assumption too, which numerous xmpp users take issue with (me incl.)
adiaholichas joined
lskdjfhas joined
restive_monkhas joined
larmaI'm not against semi-anonymous rooms, just that we either should keep that promise or give it up. not the current mix where someone with sufficient resources can deanonymize room members based on vCard and PEP
Conspicuous Obscurityhas joined
mjkwholeheartedly nods
COM8has joined
nuronhas joined
COM8has left
restive_monkhas left
arcxihas joined
pjnhas joined
larmabtw, even if we got rid of semi-anonymous rooms entirely, we still have other means of joining rooms anonymously, like 0383 burner jids
lskdjfhas left
Conspicuous Obscurityhas left
Samhas joined
marc0shas left
marc0shas joined
huhn#
Yagizahas joined
Titihas left
Titihas joined
COM8has joined
inkyhas left
COM8has left
COM8has joined
restive_monkhas joined
Conspicuous Obscurityhas joined
COM8has left
lovetoxlarma, not that its the right solution, but the problem goes away we storing your vcard and avatar on pubusb
COM8has joined
lovetoxand making the node only accesible for people you share presence with
COM8has left
lovetoxthat gives people who dont care about anonymity the choice to show their avatar to anyone, and the others not to
lovetoxif i think about it, no it does not feel right to disallow a service to request private data
lovetoxyou should store your private data in a place where you can set permissions
lovetoxthat xmpp not offered such a place was a lack of the protocol
lovetoxbut it does now
lovetoxso now its on you if you dont use it
larmalovetox, the problem does not go away, we still have weirdly broken IQ rules for MUC services. Your suggestion just solves the deanonymisation issues in MUC at the cost of features unrelated to MUCs.
lovetoxyes thats what i meant, the problem of deanonymisation
lovetoxthis goes definitly away
lovetoxweird IQ rules, i agree, but i dont see how they hurt people
lskdjfhas joined
larmaLet's say I want to share my vCard with everyone that has my JID, but still want to be (semi-)anonymous in MUCs.
lovetoxplease dont invent now use cases
larmaThat's not new, that's reality
lovetoxso store it on pubsub accessmodel=open?
lovetoxthen everybody can request it
lovetoxbut also the muc
kyemxdenhas joined
kyemxdenhas left
lovetoxif you need fine grained permission management you need to use whitelist
larmaI don't want fine-grained permission management, I want MUCs to not make everything more complicated
lovetoxand if you really need your use case, then you need to add a new protocol for that
ZashIf you go to a public place, you show your face but don't advertise your home address. Like here, avatars shown but not JIDs.
lovetoxlarma, its not complicated, i store my vcard on pubsub so only people I WANT can access it
lovetoxwhat is there complicated?
lovetoxand a MUC is just "people"
pjnhas left
kyemxdenhas joined
lskdjfhas left
larmaTo complete Zash's example: If people already know my home address, I'm fine with them being able to ring the bell to discover my face.
stphas left
stphas joined
debaclehas left
lovetoxyeah valid use case, but i dont see how thats easily possible
lovetoxthe problem with the protocol is that identitys are not easily identifiable
lovetoxthere is no sure way how you even can identify a user account
lovetoxwhat you would need is some way to treat requests from a MUC or non-user-accounts, differently
florettahas left
lovetoxbut its still possible with pubsub, but its a burden on the client developer
lovetoxhm no
lovetoxno its not possible, you basically want, the world to read your vcard, but not if they share it with others ..
lovetoxits not in your control what they do after you showed them your vcard
thilo.molitorjonas’ do you think I should incorporate my changes into the already open pull request or ceate a new one once the old one was merged?
thilo.molitorI also added a disco feature in a separate branch...same question: should I include that n the aleady open PR or should Iceate a new one for this?
kyemxdenhas left
larmalovetox: you are thinking it the wrong way round. You want to restrict access to data for services that forward it to others, when instead we could just get rid of those services.
kyemxdenhas joined
larmaBecause MUCs are the only services that forward data to users that don't have your real jid.
lovetoxbut you cant, this is a decentralized protocol, your approach would be to share your vcard and then say, pretty please dont share it
Wojtekhas joined
lovetoxit would be a solution, but not a very stable one
lovetoxits a solution depending on developers honoring your wishes
lovetoxwhen in reality you want your server to guard your data, and you should be in control with whom you share it
larmaNormally, services don't have my JID except when I explicitly tell them. And I won't tell arbitrary them when I don't believe they will follow the rules that we agreed on.✎
larmaNormally, services don't have my JID except when I explicitly tell them. And I won't tell them when I don't believe they will follow the rules that we agreed on. ✏
djorzhas joined
larmaSame as with semi-anonymous rooms I believe they won't share my real JID to everyone but just to moderators and admins
lovetoxso what are you saying? get rid of anonym mucs because they are not really anonym because you cant decide to not share your JID with them?
debaclehas joined
COM8has joined
larmaNo, I say clients should stop relying on IQs in MUCs for vCard and avatars, so MUC servers can default to disable IQs
lovetoxyeah as i said, thats just hoping for developers honoring your wishes
adiaholichas left
lovetoxdont know if hope is a good thing to depend on if at stake is your privacy
COM8has left
larmaThat's not hope. I already trust servers to follow the protocol. The problem is that the protocol just doesn't provide an important feature here.
kyemxdenhas left
kyemxdenhas joined
florettahas joined
adiaholichas joined
lovetoxfeature? nobody forces a MUC to relay IQ requests ?
larmaThe standard does
larmaOr at least suggests doing it would be good
larmaAnd clients rely on it, so they will do
Menelhas joined
larmaServer developers are not at fault here, they're just doing what client developers ask them to do
larma> I say clients should stop relying on IQs in MUCs for vCard and avatars, so MUC servers can default to disable IQs
lovetoxi dont agree with your trust argument, no case comes to mind where i trust a MUC server to do anything
nycohas left
lovetoxthats why we have e2e
jgarthas joined
larmaWhen you join semi-anonymos MUCs that announces to have logs disabled, do you expect it to publish the chat history including your real JID on a website?
COM8has joined
lovetoxno i dont expect it, but that shifts the goal, do you want to fullfill expectations? yes then i agree get rid of IQ routing rules
lovetoxdo you want to have privacy? then this is just a bandaid
COM8has left
lovetoxim not arguing that iq routing rules are something good here
larmaI want privacy when I join MUC servers where I trust the operators. Like in this MUC.
lovetoxi just think the vcard case to show it, is not a very good one
lovetoxbut yeah lets do both
lovetoxuse pubsub AND fix routing rules
lovetoxits nothing that is in opposition to each other
larmaYep
sonnyhas left
adiaholichas left
sonnyhas joined
adiaholichas joined
jgarthas left
lskdjfhas joined
lskdjfhas left
lskdjfhas joined
jgarthas joined
restive_monkhas left
pjnhas joined
jonas’thilo.molitor, small PRs are nice for review, I can merge them all at once if they fit the requirements – just make sure to *not* include a revision block then
adiaholichas left
Johnhas joined
adiaholichas joined
COM8has joined
rafasaurushas left
lskdjfhas left
Thilo Molitorhas left
COM8has left
Thilo Molitorhas joined
Thilo Molitorjonas’: okay, thanks :)
COM8has joined
restive_monkhas joined
atomicwatchhas left
COM8has left
rafasaurushas joined
COM8has joined
BASSGODhas left
COM8has left
atomicwatchhas joined
jgarthas left
bunghas joined
kyemxdenhas left
norkkihas left
kyemxdenhas joined
wladmishas joined
sonnyhas left
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
BASSGODhas joined
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
emushas joined
lorddavidiiihas left
nycohas joined
lorddavidiiihas joined
sonnyhas joined
papatutuwawahas joined
BASSGODhas left
Menelhas left
Menelhas joined
lorddavidiiihas left
kyemxdenhas left
adiaholichas left
kyemxdenhas joined
florettahas left
florettahas joined
adiaholichas joined
norkkihas joined
kyemxdenhas left
kyemxdenhas joined
lskdjfhas joined
kyemxdenhas left
kyemxdenhas joined
wladmishas left
harry837374884has left
harry837374884has joined
u70jfzo5eyeb468b9ohas joined
bungXMPP <3
adiaholichas left
adiaholichas joined
COM8has joined
mjkhas left
lskdjfhas left
mjkhas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
stphas left
BASSGODhas joined
COM8has left
jgarthas joined
sabryhas joined
COM8has joined
Johnhas left
BASSGODhas left
COM8has left
Menelhas left
sabryhas left
Nekithas left
Menelhas joined
adiaholichas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
sonnyhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
karoshihas left
lorddavidiiihas joined
lorddavidiiihas left
karoshihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Johnhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Nekithas joined
kyemxdenhas left
kyemxdenhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
COM8has joined
neshtaxmpphas joined
COM8has left
lorddavidiiihas joined
mjkhas left
lorddavidiiihas left
lorddavidiiihas joined
mjkhas joined
lorddavidiiihas left
bunghas left
lorddavidiiihas joined
Link MauveRe 0363, at no place it specifies that HTTP headers are case insensitive, would it be useful to say that?
lorddavidiiihas left
sabryhas joined
Link MauveI took HTTP for granted, but I’m reviewing an implementation which only accepts Title-Case headers.
jonas’Link Mauve, what. yeah.
jonas’might be worth making it explicit, in addition to the fact that multiple values may be present and that their order must be preserved and they must all be passed to the HTTP server
lorddavidiiihas joined
lorddavidiiihas left
Link MauveI couldn’t figure out how to say that in the schema though.
Link MauveDo we have any other similar case in the protocols?
Neustradamus XML Schema for the 'jingle' namespace: <http://xmpp.org/schemas/jingle.xsd>
lorddavidiiihas joined
HolgerEverything is broken.
lorddavidiiihas left
ZashI'm in it to increase web related suffering as revenge for not adopting SRV records! 😉
robertooohas left
Ellenor Malik???
robertooohas joined
marc0shas left
marc0shas joined
mjkhas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
mjkhas joined
dan.caseleyhas left
dan.caseleyhas joined
HolgerEllenor Malik, there's SRV records such as `_xmpp-client._tls.example.com` to point XMPP clients to the server handling the example.com domain, which might be `xmpp.example.com`. There's no `_http._tcp` record to point browsers querying https://example.com to the actual server handling that query, e.g. www.example.com. The absence of support for such SRV records is part of the reason why the `www.` subdomain got popular.
HolgerYes, there's HTTPS, which would require `_https._tcp` records, if there was SRV support in the first place.
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
ZashThere was starttls for http somewhere
COM8has joined
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
neshtaxmpphas left
neshtaxmpphas joined
mjk`Location: https://...`?
Calvinhas left
mjkWait, disregard that
lorddavidiiihas joined
lorddavidiiihas left
BASSGODhas left
Link MauveIt might be useful to add HSTS Preload to our HSTS header, so that xmpp.org would be included in the list of domains which always want TLS on HTTP, shipped with browsers.
lorddavidiiihas joined
lorddavidiiihas left
mjk> www. in URLs is that it serves as a gentle reminder that there are other services than the Web
I prefer `web.` for that. More explicit and doesn't suggest the domain serves a site _about_ w3
wladmishas left
ZashI'm a fan of this myself
```
set $should_upgrade "$https$http_upgrade_insecure_requests";
if ($should_upgrade = "1") {
return 307 https://$host$request_uri;
}
```
adiaholichas joined
COM8has left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Link MauveI stopped serving anything on port 80 some year ago, after years of doing that redirect, and nothing broke because of HSTS Preload.
Holgermjk, I'm not sure how large the proportion of users is that will be confused by "www" suggesting a site about the web technology 😉
mjkLink Mauve: do browser vendors actually harvest the interwebs for HSTS headers? My impression of the technology always was that each browser installation learns on its own
lorddavidiiihas joined
Link MauveWhich freed it for certificate retrieval as well as the occasional proxy bypass port.
lorddavidiiihas left
HolgerBut the whole reminder idea is nonsense of course, except that you might be happy about being reminded if you knew anyway.
Link Mauvemjk, no, you go to https://hstspreload.org/ and request your domain to be added there.
lorddavidiiihas joined
Link MauveIt will check that you do serve the HSTS Preload header, so that no one but the website owner can include this header in browsers’ lists.
lorddavidiiihas left
mjkHolger: probably in minus 6th order of 10. :) But I sleep better
Holger🙂
COM8has joined
Link Mauvemjk, the process is explained on that website.
mjkLink Mauve: ah, TIL, thanks
lorddavidiiihas joined
lorddavidiiihas left
jonas’Link Mauve, also firefox now has that annoying behaviour to try https if something goes wrong on http. (which adds to the "not serving port 80 doesn't break anything")
COM8has left
jonas’it is about as annoying as it adding .com or whatnot to a domain name if something goes wrong
Link MauveOh, TIL about this behaviour.
lorddavidiiihas joined
COM8has joined
lorddavidiiihas left
millesimushas left
lorddavidiiihas joined
lorddavidiiihas left
COM8has left
lorddavidiiihas joined
lorddavidiiihas left
mjkAnnoying for debugging port 80 issues, I guess. But the .com thing is just... ugh, whyyyy
jonas’mjk, it's also annoying for developing locally when your dev server just crashed and you get "redirected" by firefox to https and you don't notice and then f5 won't do anthing anymore because it's going to 443 instead of 80 now.