XSF Discussion - 2020-02-22

RFC 6120, 13.10.1. Any particular reason?

Ellenor Malik: IP addresses can leak various information, such as your location

that doesn't stop other protocols from doing it.

That doesn't mean it's a good thing :)

there isn't a reason for it to be a MUST NOT. STRONGLY DISCOURAGED for the reasons you describe (which I agree with, by the way, it's why I've loaded the cloaking module on my IRC server, to reduce the granularity of the hostname display) would make total sense, but MUST NOT does not.

Well in the 9 years since publication I don't recall anyone so far who has said "I wish the RFC allowed making my users' IP addresses public"

it's sort of a spitball

also, would including an ad hoc that would allow the user to disclose their IP of their own volition violate the RFC? since it's the user disclosing and not technically the server...?

There are cases where the IP is already disclosed directly and indirectly by the client

When you do a direct file transfer your client will typically try to obtain your external IP and send it to the recipient (the recipient may also do the same)

And indirectly through fetching HTTP upload shares, though that doesn't happen over the XMPP channel

And yeah, if the client and server negotiate that revealing the IP address is ok, I think that's fine

it would make more sense for the MUC specification to require directly-used clients (like gajim, conversations, etc) to implement a MUC block feature so you can at least do nick-based ignores like on IRC

Many clients do that already, why would you require that kind of thing in the specification?

show me one, because none of the clients I have encountered do that.

poezio

Jarkko is probably gonna call the XSF in the next 10 years and just be like "y'all could use the Q:line that I put in Internet Relay"

Umbrellix will become the Eris of Jabber.