XSF Discussion - 2018-01-04

Hi all

Hey

What? End of Meeting?

0. Welcome and agenda

Who do we have?

I'm here

Guus and Martin both said they couldn't make it today

right

and no nyco?

Ok, so no quorum. Let's try next week and follow up on list.

wfm

ralphm: don't forget to change the topic for our multi-year ongoing Board meeting

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

There

Phew!

thanks very much.

BTW, whom should I approach about the administration of jabber.org and xmpp.org the Jabber servers?

stpeter maybe?

xmpp.org is iteam

xmpp.org isn’t a public server in any way though

AFAIK

Iteam for xmpp.org. Peter for jabber.org. Although you can always approach me and see if I can help.

Maybe I should just make it (more) public now.

your manifesto?

Kev: 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

if only the third item was possible

mathieui: monitoring registrations from TOR?

yes

mathieui: it is possible, at least on prosody

I think it's millions of users, FWIW, although not all active.

jabber.org has millions of registered users on its own.

well, if "monitoring" consists of adding one log line to the prosody debug file, then sure, it’s possible

but also useless

mathieui: you can have a script grep your log

And do what

Xmpp over tor is perfectly legitimate

moparisthebest, treat the accounts with more scrunity until it’s clear they’re not abusers?

limit resource usage etc.

moparisthebest, it’s perfectly legitimate but mass account creation is not

protecting public servers against tor-helped abuse is also perfectly legitimate :)

jonasw: sounds hard for a script but sounds ok

also from my homemade statistics we’ve got around 1000 registrations for one legitimate user from those ips

> protecting public servers against tor-helped abuse is also perfectly legitimate :) We really need to differentiate here. There _are_ legitimate use cases for Tor

Ge0rG, that’s why I’m saying "tor-helped abuse" and not "tor itself"

yeah, it’s not about banning Tor at all (hell, I run a relay myself)

So will there be a public list of servers that should be blocked or will that be up to individual servers to determine

I suggested to run a public DNS block list

but Ge0rG was against the name I proposed :)

That would be ideal, but then someone has to manage it

I wanted to try that

The reason it's ideal is because large servers have enough info to determine bad domains, small servers do not

yes

And I'm biased, I'm the only one on my server to get spam :)

jonasw: I was not opposed to you actually running it, but you might give it a better name, like xmpp-rbl

I know

RBL doesn’t seem to be a reasonable name though

because it won’t be real-time or blackhole, will it?

Is there any reason for it to be DNS-based for XMPP?

Kev, exploiting existing cache infrastructures and speed?

But you're talking about running your own, aren't you?

what does that have to do with anything?

with existing cache infrastructtures, I mean global and local resolvers

"Exploiting existing infrastructure" and "bringing your own new infrastructure" don't seem compatible.

DNS is also easily replicated

Anyway, I don't have a particular reason it needs to not be DNS.

jabber.org doesn't have offline storage :(

It doesn't?

Nope.

I don't remember that being disabled.

At least I get `503 - cancel: Service unavailable` when messaging stpeter

I just tested on myself, and it worked.

I never was able to message stpeter when he wasn't online.

subscribed?

yep

syn?

syn ack

syn?

wow, took a,long time to send but apparently I can connect for free on Delta flights' terrible wifi.

SamWhited: your `syn?` was delivered twice.

yeah

I have that from time to time with conversations

odd

SM resume fails so Conversations resends to fail on the safe side?

They 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.

SIP, even.

Holger: shouldn't it wait for the MUC sync to complete before re-sending?

SamWhited: maybe they are only blocking HTTP(S) ;)

(SM resume fails and the server doesn't include the 'h' attribute with the <failed/> response, that is ...)

Ge0rG, this muc is anonymous, isn’t it?

so there’s no point in syncing

Ge0rG: How would that help?

jonasw: right, all bets are off.

Holger, if you received the history in a non-anon muc you could be sure whether your message got delivered :)

personally, I just ignore impersonation attacks and sync away.

jonasw: Hm with some proper ID (origin-id?) I guess so, yes.

Ge0rG, how did our discussion of user invitation URI end? Do we need the "ibr" query parameter?

marc: yes

Ge0rG, in what case?

I remeber I agreed that we don't need an action parameter :)

marc: the ibr parameter indicates that the preauth token can be used in an IBR request to the server

Ge0rG, but the authority part of the URI already indicates it

marc: wait, we are talking of account invitation?

marc: we need a good glossary

Ge0rG, no, "account creation" uses the "register" action query :)

marc: so how does the contact invitation indicate ibr?

Ge0rG, xmpp://example.com/inviter@example.com?preauth=TOKEN

xmpp:inviter@example.com?preauth=TOKEN for client-side PARS

did you mean https for the first one marc ?

marc: so which one of those?

Okay, wait

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

moparisthebest, no

xmpp:inviter@example.com?preauth=TOKEN;ibr is a perfect match for both second and third use case

Ge0rG, no

And the account invitation doesn't need the inviter URL

The authority part can indicate the domain to create an account

not really sure the need for all the different urls but I'll just shut up until I see xep :P

moparisthebest, no, just ask

well what do each of those do?

marc: you are making it too complicated

and why are there more than one format if all have to be handled by xmpp client?

moparisthebest, 1: create an account, 2: invite a user and give the choice to register on the server 3: PARS

marc: stop adding edge cases. If the inviter and invitee domains differ, this is not our use case any more

hmm how is 1 different than 2 ?

like how would you get link #1

moparisthebest, #1 is more or like admin stuff

so why isn't it the same?

Ge0rG, don't get why this makes it more complicated than using an additional "ibr" parameter

I still don't see any reason for more than 1 url

whatever it may be

it looks like all those have exactly the same info in slightly different formats, why?

moparisthebest, no, they don't

moparisthebest, because they are different? ;)

what is different

what info do they have?

bet you wish you would have just let me wait for xep now lol

you can go back to ignoring me if you want I don't mind :)

moparisthebest, #1: contains the new account JID (newuser@example.com)

moparisthebest, #2 contains the domain for IBR (example.com)

do they not all contain domain for IBR ?

marc: just completely delete #2

so looks like 1 & 2 are same except extra useless 'register' and optional account name

Ge0rG, we already agreed on it ;)

marc: on deleting it

And implementing the same functionality in #3

And IIRC you liked the idea of different domains

what does 'register' get you?

moparisthebest, indicates account registration

doesn't newuser@ indicate that?

moparisthebest, no, because newuser is optional :P

So what does it do differently

moparisthebest, as I said, you could have xmpp://example.com/inviter@example.com?register;preauth=TOKEN

But don't tell Ge0rG :D

marc: that won't work if the invitee already has an account!

marc: point being you have to check if they have an account or not already so I think it's useless

And how do you validate it meh

Ge0rG, don't get your point

Ge0rG, you're talking about #1, right?

marc: no, #2

Ge0rG, okay, what's the problem if the invitee already has an account?

Why doesn't it work? You just show an dialog to add via the PARS token

And show a short button or whatever that the invitee can also create an account on the server

marc: because you need a #3 link for that to work

s/short/small

Ge0rG, why?

Ge0rG, if the server doesn't support this XEP the client can generate #3 itself

As fallback, the user doesn't even notice it

The same applies if the server doesn't allow IBR for invitation

It just sends #3

(This is what you describe as server-side PARS in your XEP)

marc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported

marc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported

Ge0rG, if these clients are implemented correctly it is even backward compatible ;)

Ge0rG, #2 is backward compatible to #3 if you parse the URI properly IMO

marc: no, it's something different

Ge0rG, if you correctly parse the #3 URI you would extract the JID from the "path" component

The same for #2

Ge0rG, in #3 the authority part is empty and the JID in the "path" component

marc: except that #2 has completely weird semantics with a host as the authority

marc: just leave it away, please

Ge0rG, that's the sematinc of XMPP URIs

Ge0rG, xmpp:///inviter@example.com?preauth=TOKEN if no domain is provided

"this URI points to a jabber server."

marc: xmpp:inviter@domain;preauth;ibr is an invitation to a user JID, with the hint that you can register on that domain

Ge0rG, but you can not provide a good argument why that's a better solution ;)

marc: I've provided multiple good arguments multiple times already

Ge0rG, both are backward compatible

marc: I'm on my mobile client right now, and I really don't want to repeat them all

marc: there are no clients supporting #2 dnd it has the wrong semantics

Ge0rG, #1 has the same wrong semantic then?

marc: #1 is sharing an account on a server

Ge0rG, okay, what about xmpp://example.com?register;preauth=TOKEN (#1 without specified username)?

marc: I still think we could completely cover most situations with just #3, but #1 adds some value

marc: nope! Use #3

Ge0rG, I'm talking about #1 scenario

Ge0rG, is this URI correct?

for #1 scenario...

No trick question ;) I'll use "ibr" for user invitation

marc: if you don't supply a username, just skip the authority completely

Hm, 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

If the server doesn't support this XEP the client generates #2 itself

Okay?

marc: yes

Ge0rG, okay, I'll adapt the XEP accordingly

marc, is the (proto)xep online somewhere?

marc: that is exactly what we agreed about, plus account invitation with xmpp://invitee@domain with a token

Flow, no, but I can upload it tomorrow or so

+1