Ge0rGBTW, whom should I approach about the administration of jabber.org and xmpp.org the Jabber servers?
jonaswstpeter maybe?
jonaswxmpp.org is iteam
jonaswxmpp.org isn’t a public server in any way though
jonaswAFAIK
KevIteam for xmpp.org. Peter for jabber.org. Although you can always approach me and see if I can help.
Ge0rGMaybe I should just make it (more) public now.
jonaswyour manifesto?
Ge0rGKev: I'm working on a Public Servers Anti-Spam manifesto - https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e - I'd like to get some feedback from large public servers' admins to create a consensus that can be signed off
mathieuiif only the third item was possible
Ge0rGmathieui: monitoring registrations from TOR?
mathieuiyes
Ge0rGmathieui: it is possible, at least on prosody
KevI think it's millions of users, FWIW, although not all active.
Kevjabber.org has millions of registered users on its own.
mathieuiwell, if "monitoring" consists of adding one log line to the prosody debug file, then sure, it’s possible
mathieuibut also useless
Ge0rGmathieui: you can have a script grep your log
moparisthebestAnd do what
moparisthebestXmpp over tor is perfectly legitimate
jonaswmoparisthebest, treat the accounts with more scrunity until it’s clear they’re not abusers?
jonaswlimit resource usage etc.
mathieuimoparisthebest, it’s perfectly legitimate but mass account creation is not
jonaswprotecting public servers against tor-helped abuse is also perfectly legitimate :)
moparisthebestjonasw: sounds hard for a script but sounds ok
mathieuialso from my homemade statistics we’ve got around 1000 registrations for one legitimate user from those ips
Ge0rG> protecting public servers against tor-helped abuse is also perfectly legitimate :)
We really need to differentiate here. There _are_ legitimate use cases for Tor
jonaswGe0rG, that’s why I’m saying "tor-helped abuse" and not "tor itself"
mathieuiyeah, it’s not about banning Tor at all (hell, I run a relay myself)
moparisthebestSo will there be a public list of servers that should be blocked or will that be up to individual servers to determine
jonaswI suggested to run a public DNS block list
jonaswbut Ge0rG was against the name I proposed :)
moparisthebestThat would be ideal, but then someone has to manage it
jerehas joined
jonaswI wanted to try that
moparisthebestThe reason it's ideal is because large servers have enough info to determine bad domains, small servers do not
jonaswyes
moparisthebestAnd I'm biased, I'm the only one on my server to get spam :)
lumihas joined
waqashas joined
Ge0rGjonasw: I was not opposed to you actually running it, but you might give it a better name, like xmpp-rbl
jonaswI know
jonaswRBL doesn’t seem to be a reasonable name though
jonaswbecause it won’t be real-time or blackhole, will it?
KevIs there any reason for it to be DNS-based for XMPP?
jonaswKev, exploiting existing cache infrastructures and speed?
KevBut you're talking about running your own, aren't you?
jonaswwhat does that have to do with anything?
jonaswwith existing cache infrastructtures, I mean global and local resolvers
Kev"Exploiting existing infrastructure" and "bringing your own new infrastructure" don't seem compatible.
jonaswDNS is also easily replicated
KevAnyway, I don't have a particular reason it needs to not be DNS.
Ge0rGjabber.org doesn't have offline storage :(
KevIt doesn't?
Ge0rGNope.
KevI don't remember that being disabled.
Ge0rGAt least I get `503 - cancel: Service unavailable` when messaging stpeter
KevI just tested on myself, and it worked.
Ge0rGI never was able to message stpeter when he wasn't online.
jonaswsubscribed?
Ge0rGyep
Ge0rGhas left
dwdhas joined
lumihas left
jjrhhas left
SamWhitedhas joined
SamWhitedsyn?
Ge0rGsyn ack
SamWhitedhas left
SamWhitedsyn?
SamWhitedwow, took a,long time to send but apparently I can connect for free on Delta flights' terrible wifi.
Ge0rGSamWhited: your `syn?` was delivered twice.
mathieuiyeah
mathieuiI have that from time to time with conversations
SamWhitedodd
HolgerSM resume fails so Conversations resends to fail on the safe side?
SamWhitedThey claim to only allow Whatsapp, Facebook, and sonething else for free but I can use my server and jmp.chat's SI. server, this is rather nice.
SamWhitedSIP, even.
Ge0rGHolger: shouldn't it wait for the MUC sync to complete before re-sending?
Ge0rGSamWhited: maybe they are only blocking HTTP(S) ;)
Holger(SM resume fails and the server doesn't include the 'h' attribute with the <failed/> response, that is ...)
jonaswGe0rG, this muc is anonymous, isn’t it?
jonaswso there’s no point in syncing
HolgerGe0rG: How would that help?
Ge0rGjonasw: right, all bets are off.
jonaswHolger, if you received the history in a non-anon muc you could be sure whether your message got delivered :)
Ge0rGpersonally, I just ignore impersonation attacks and sync away.
Holgerjonasw: Hm with some proper ID (origin-id?) I guess so, yes.
lskdjfhas joined
zinidhas joined
Syndacehas left
Syndacehas joined
Kevhas left
Guushas left
tim@boese-ban.dehas left
SamWhitedhas joined
la|r|mahas left
la|r|mahas joined
Guushas left
jjrhhas left
jjrhhas left
jjrhhas left
hanneshas joined
lovetoxhas joined
SamWhitedhas joined
zinidhas left
mimi89999has joined
lskdjfhas joined
lskdjfhas joined
dwdhas left
dwdhas left
hanneshas left
hanneshas joined
lumihas joined
tuxhas left
goffihas left
Lancehas joined
Lancehas left
efrithas joined
jerehas left
jerehas joined
efrithas left
efrithas joined
Kevhas left
hanneshas left
hanneshas joined
suzyohas joined
danielhas left
danielhas joined
remkohas left
Lancehas joined
jjrhhas left
jjrhhas left
SouLhas joined
SouLhas joined
suzyohas joined
@Alacerhas left
waqashas left
@Alacerhas joined
jjrhhas left
ralphmhas left
remkohas left
jjrhhas left
efrithas left
Steve Killehas left
jjrhhas left
dwdhas left
suzyohas joined
Steve Killehas left
dwdhas joined
Steve Killehas joined
jjrhhas left
uchas joined
dwdhas left
hanneshas left
la|r|mahas joined
hanneshas joined
Steve Killehas left
jjrhhas left
Syndacehas left
ralphmhas left
danielhas left
jerehas joined
jerehas joined
dwdhas joined
Syndacehas joined
jerehas left
jerehas joined
zinidhas joined
hanneshas left
hanneshas joined
Tobiashas joined
remkohas left
Tobiashas joined
hanneshas left
hanneshas joined
jerehas joined
jerehas joined
waqashas joined
lskdjfhas left
lskdjfhas left
andrey.ghas left
goffihas joined
Lancehas joined
lskdjfhas joined
jjrhhas left
jjrhhas left
mimi89999has joined
jjrhhas left
la|r|mahas left
lskdjfhas left
hanneshas left
valohas joined
hanneshas joined
danielhas left
lskdjfhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
ralphmhas left
lskdjfhas left
lskdjfhas left
dwdhas left
danielhas left
dwdhas left
Alexhas left
intosihas left
Lancehas joined
dwdhas left
dwdhas left
SamWhitedhas left
Alexhas joined
SouLhas joined
ralphmhas left
ralphmhas joined
ralphmhas left
ralphmhas joined
zinidhas left
ralphmhas joined
dwdhas joined
goffihas left
Alexhas left
hanneshas left
hanneshas joined
Alexhas joined
Lancehas left
dwdhas left
andrey.ghas joined
dwdhas joined
marcGe0rG, how did our discussion of user invitation URI end? Do we need the "ibr" query parameter?
dwdhas left
danielhas left
valohas joined
dwdhas joined
Ge0rGmarc: yes
marcGe0rG, in what case?
marcI remeber I agreed that we don't need an action parameter :)
lskdjfhas joined
Ge0rGmarc: the ibr parameter indicates that the preauth token can be used in an IBR request to the server
marcGe0rG, but the authority part of the URI already indicates it
Ge0rGmarc: wait, we are talking of account invitation?
Ge0rGmarc: we need a good glossary
marcGe0rG, no, "account creation" uses the "register" action query :)
Ge0rGmarc: so how does the contact invitation indicate ibr?
marcxmpp:inviter@example.com?preauth=TOKEN for client-side PARS
moparisthebestdid you mean https for the first one marc ?
Ge0rGmarc: so which one of those?
marcOkay, wait
marc
Account creation: xmpp://newuser@example.com/inviter@example.com?register;preauth=TOKEN
User invitation: xmpp://example.com/inviter@example.com?preauth=TOKEN
Client-side PARS: xmpp:inviter@example.com?preauth=TOKEN
marcmoparisthebest, no
Ge0rGxmpp:inviter@example.com?preauth=TOKEN;ibr is a perfect match for both second and third use case
marcGe0rG, no
Ge0rGAnd the account invitation doesn't need the inviter URL
marcThe authority part can indicate the domain to create an account
moparisthebestnot really sure the need for all the different urls but I'll just shut up until I see xep :P
marcmoparisthebest, no, just ask
moparisthebestwell what do each of those do?
Ge0rGmarc: you are making it too complicated
moparisthebestand why are there more than one format if all have to be handled by xmpp client?
marcmoparisthebest, 1: create an account, 2: invite a user and give the choice to register on the server 3: PARS
Ge0rGmarc: stop adding edge cases. If the inviter and invitee domains differ, this is not our use case any more
moparisthebesthmm how is 1 different than 2 ?
moparisthebestlike how would you get link #1
marcmoparisthebest, #1 is more or like admin stuff
moparisthebestso why isn't it the same?
marcGe0rG, don't get why this makes it more complicated than using an additional "ibr" parameter
moparisthebestI still don't see any reason for more than 1 url
moparisthebestwhatever it may be
moparisthebestit looks like all those have exactly the same info in slightly different formats, why?
marcmoparisthebest, no, they don't
marcmoparisthebest, because they are different? ;)
moparisthebestwhat is different
moparisthebestwhat info do they have?
moparisthebestbet you wish you would have just let me wait for xep now lol
moparisthebestyou can go back to ignoring me if you want I don't mind :)
marcmoparisthebest, #1: contains the new account JID (newuser@example.com)
marcmoparisthebest, #2 contains the domain for IBR (example.com)
moparisthebestdo they not all contain domain for IBR ?
Ge0rGmarc: just completely delete #2
moparisthebestso looks like 1 & 2 are same except extra useless 'register' and optional account name
marcGe0rG, we already agreed on it ;)
Ge0rGmarc: on deleting it
Ge0rGAnd implementing the same functionality in #3
marcAnd IIRC you liked the idea of different domains
marcmoparisthebest, no, because newuser is optional :P
moparisthebestSo what does it do differently
marcmoparisthebest, as I said, you could have xmpp://example.com/inviter@example.com?register;preauth=TOKEN
marcBut don't tell Ge0rG :D
danielhas left
Ge0rGmarc: that won't work if the invitee already has an account!
moparisthebestmarc: point being you have to check if they have an account or not already so I think it's useless
moparisthebesthas joined
moparisthebestAnd how do you validate it meh
ralphmhas joined
marcGe0rG, don't get your point
marcGe0rG, you're talking about #1, right?
Ge0rGmarc: no, #2
marcGe0rG, okay, what's the problem if the invitee already has an account?
marcWhy doesn't it work? You just show an dialog to add via the PARS token
marcAnd show a short button or whatever that the invitee can also create an account on the server
Ge0rGmarc: because you need a #3 link for that to work
marcs/short/small
marcGe0rG, why?
marcGe0rG, if the server doesn't support this XEP the client can generate #3 itself
marcAs fallback, the user doesn't even notice it
la|r|mahas left
marcThe same applies if the server doesn't allow IBR for invitation
marcIt just sends #3
marc(This is what you describe as server-side PARS in your XEP)
jjrhhas left
Ge0rGmarc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported
Ge0rGhas left
Ge0rGmarc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported
marcGe0rG, if these clients are implemented correctly it is even backward compatible ;)
marcGe0rG, #2 is backward compatible to #3 if you parse the URI properly IMO
Ge0rGmarc: no, it's something different
marcGe0rG, if you correctly parse the #3 URI you would extract the JID from the "path" component
marcThe same for #2
bluelinerhas joined
marcGe0rG, in #3 the authority part is empty and the JID in the "path" component
Ge0rGmarc: except that #2 has completely weird semantics with a host as the authority
Ge0rGmarc: just leave it away, please
marcGe0rG, that's the sematinc of XMPP URIs
marcGe0rG, xmpp:///inviter@example.com?preauth=TOKEN if no domain is provided
Ge0rG"this URI points to a jabber server."
Ge0rGmarc: xmpp:inviter@domain;preauth;ibr is an invitation to a user JID, with the hint that you can register on that domain
marcGe0rG, but you can not provide a good argument why that's a better solution ;)
ralphmhas joined
Ge0rGmarc: I've provided multiple good arguments multiple times already
marcGe0rG, both are backward compatible
Ge0rGmarc: I'm on my mobile client right now, and I really don't want to repeat them all
Ge0rGmarc: there are no clients supporting #2 dnd it has the wrong semantics
marcGe0rG, #1 has the same wrong semantic then?
Ge0rGmarc: #1 is sharing an account on a server
marcGe0rG, okay, what about xmpp://example.com?register;preauth=TOKEN (#1 without specified username)?
Ge0rGmarc: I still think we could completely cover most situations with just #3, but #1 adds some value
Ge0rGmarc: nope! Use #3
marcGe0rG, I'm talking about #1 scenario
marcGe0rG, is this URI correct?
marcfor #1 scenario...
marcNo trick question ;) I'll use "ibr" for user invitation
dwdhas left
Ge0rGmarc: if you don't supply a username, just skip the authority completely
marcHm, I don't know but we agree on the following:
User invitation: xmpp:inviter@example.com?preauth=TOKEN;ibr
User invitation (without IBR, server-side PARS) xmpp:inviter@example.com?preauth=TOKEN
marcIf the server doesn't support this XEP the client generates #2 itself
marcOkay?
Ge0rGmarc: yes
marcGe0rG, okay, I'll adapt the XEP accordingly
Flowmarc, is the (proto)xep online somewhere?
Ge0rGmarc: that is exactly what we agreed about, plus account invitation with xmpp://invitee@domain with a token