jdev - 2020-04-21

no

why? so MAM does archive it?

or so clients that dont support direct can display something

lovetox: both of those, yeah

also for Carbons to work

appears that including a fallback body should become a pattern (at least in some cases)

flow: it's been a pattern for twenty years

most MUC implementations send a fallback body in direct invites.

it's also mostly very ugly

then it's not a widely known one and at least not specified in xep249 ✏

Ge0rG, sending a fallback body with xep249 direct muc invitations is ugly? care to elaborate?

flow: feel free to PR, I guess

flow: no, the fallback body generated by MUC implementations is ugly

The direct invite included in the meditated invite is also fun

flow: it would be great to have a small section in 0249 discussing that a) a fallback body MAY be added by the sender and that if it is added, it MUST NOT contain any information that's not in the <x/>, so that it is safe to ignore by compliant implementations

when do i want to send an directed invite instead of a mediated one?

lovetox, when your recipient filters messages from strangers

i cant know that

(since the MUC is going to be a stranger)

exactly

so the answer is "always, unless you have to go mediated because of ACLs"

so it cant be factor in my decision

but mediated invite adds automatically to member list

that’s what I meant

if you are in members-only and you are not an admin, you have to go mediated

if you are in members-only and you are an admin, you add them to the member list and send direct

otherwise, you send direct

omg, way too complicated

yes

somebody should write some flowchart

I just did :)

in text form tho

flowchart in text form i have to remember that :D

lovetox, "way too compliacted" implies that there is a less complicated way. Please share that :)

i dont see how one implys the other

0401 ish flow for MUC?

quantum physic is also way to complicated for me, that does not mean there is an easier way :)

https://paste.debian.net/hidden/727768a8/ ✏

oh, now the nice flow chart is gone :(

flow, it was only nice if you have a mono-spaced font

great thanks jonas’

ahh true :)

lovetox, if you’re smart, you put this somewhere sane ;)

because that paste expires in 7d

PR that in xep45, otherwise it will be gone forever in 7d?

flow, maybe rather in the XEP for invites?

or that

https://xmpp.org/extensions/xep-0249.html

jonas’, I wonder: was that hand crafted or did you use some tool?

http://asciiflow.com ✏

flow, note that it has nothing to do with re-encoding you in ASCII, no worries.

Yes, good, I like my DNA-based encoding

and how to deal with invites received through MAM?

obviously i check if its already in my bookmarks, but what if not?

check the date? and only show if its the near past?

lovetox, sadly the MAM archive does not contain the information if the user decided to not follow the invitation

Joining every room I was ever invited to is a bit annoying, so don't do that maybe

one could store rejected invitations with a timestamp in a private pep node

yeah wondering how clients deal with that which implement auto join on invite

> check the date? and only show if its the near past? Can you create something like a bookmark with 'do not join, declined' info? ✏

Martin, you can

Ah, what flow said.

but someone has to implement it ;)

if only we had a mechanism where the server tracks inbound requests and ack/naks for those

but i can decline a invite, why would it not be stored in mam?

its a message

there is not really a nack for rejected invitations?

``` $ graph-easy --as=ascii <<. graph "test" { foo -> { bar boo } -> baz } . +-----+ +-----+ | boo | <-- | foo | +-----+ +-----+ | | | | | v | +-----+ | | bar | | +-----+ | | | | | v | +-----+ +-------> | baz | +-----+ ```

in groupchat 1.0, (mediated) invites could’ve been presence subscription requests which are indeed tracked by the server. Doesn’t solve it for the non-insane post-GC-1.0 world, nor for mediated invites, but it still crossed my mind.

Pretty sure there's a way to reject invites

https://xmpp.org/extensions/xep-0045.html#example-59

Nice, so problem solved? ✏

not for '249 though?

Could also keep bookmarks around for some with autojoin=false after you left

Maybe invent a bookmarks2 'trash' flag?

can't xep249 simply re-use xep45 decline (even though it currently states to silently discard) ✏

What if you accept, but later leave?

Zash, dunno, using muc bookmarks for mucs you are not really interested in seems not right

And then a fresh client syncs MAM, sees the invite and joins the room that you wanted nothing to do with anymore.

meh

Needs more flowcharts!

you *could* reject an invite, but why should you?

invited -> rejected -> ensure rejection is saved somewhere invited -> accepted -> bookmarked -> leave -> ???

autojoin=1 -> yes, autojoin=0 -> keep in mind but don't join, autojoin=-1 -> blacklisted!

but it's a boolean

autojoin=0 -> keep in mind but don't join, autojoin=n -> blacklisted!

won't prosody keep the actual textual representation in the store?

Other clients parsing and re-serializing it tho?

Zash: who cares about other clients?

oh wait, you can just block the room JID and manually compare direct invites to the blocklist

Heh, hacky but I suppose it would work

And it would prevent unknowing clients from joining

lovetox: there is one more reason for direct invites: you might want to auto-join invites to private rooms from a contact, because insta-chats. And you can't ensure that a mediated invite really came from a contact and not from a malicious MUC

Zash> And it would prevent unknowing clients from joining hopefully with a nice error message instead of a silent timeout

i'm also not sure about the UX if the user afterwards decides that to join the room

Blocking command mandates an error iirc

Hm

what would be the 'from' value of the iq error?

> If the user attempts to send an outbound stanza to the JID, the user's server MUST NOT route the stanza to the JID but instead MUST return a <not-acceptable/> error [...] https://xmpp.org/extensions/xep-0191.html#block https://xmpp.org/extensions/xep-0191.html#example-9

flow, /error/@by is what you mean

@to & @from are always swapped for replies

ahh good then

Not sure we set that tho, better check

It's not in the example, so probably not :)

Heh, indeed

> Zash> but it's a boolean or why one shouldn't represent booleans as integers :(

pep.: as we all know, the correct represntation for booleans is ["YES", "Norway"]

:D

I’ll just leave this here: $ host omdathetkan.monshouwer.org omdathetkan.monshouwer.org is an alias for https://omdathetkan.monshouwer.org. https://omdathetkan.monshouwer.org has address 195.191.112.29 https://omdathetkan.monshouwer.org has IPv6 address 2a02:990:100:1:0:d05::

(re that discussion the other day about nameprep being not strict enough)

jonas’, hmm, I am not sure if (other) non-LDH labels should appear on the wire

non-LDH?

ldh: letters digits hyphen ✏

it was my understanding that essentially only those are allowed in the wire protocol

what about _xmpp-server

there was a fun discussion in #powerdns on OFTC a few minutes back (after I asked if '&' (U+0026) is valid in DNS labels) and DNS isn’t actually strict about that

those are underscore labels

dns is like 1000s of RFCs, so its kind of complicated

plus registries are lax when it comes to compliance

which kinda forces implementations to become a little bit lax too

compliance to what even

the RFCs i'd assume

hmm it was pretty sure the kind of labels which are allowed on the wire is specified somewhere

flow, maybe you meant: https://tools.ietf.org/html/rfc1035 <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9

but that seems to be generally understood more as "guideline" than as "rule" by the DNS community

yes and no, that's one of the very first of DNS related RFCs

there are many updates to this

indeed ✏

but if the powerdns folks tell me that, I’m not going to argue ;)

I don’t want to be *that* person who tries to point at RFCs in a field they don’t know about in front of the folks implementing them all day ;)

jonas’, they tell you it is valid?

yes

could very well be, as I said i'm not sure

I hear that there are not really restrictions

there’s something for "hostnames", but that’s irrespective of DNS

as you can see, the https:// stuff passing right through

powerdns will reject & and ; with the SQL backend tho

so no fun to be had with &quot;.domain.example and XML

and '://' is not really the interesting part of the ASCII range ✏

Ge0rG, you might enjoy `dig 🤖️.zash.se txt +noidnin`

I get NXDOMAIN

but that may be copy/paste issues

`dig txt bender.zash.se` but it gets escaped :(

ahh, possible that https://tools.ietf.org/html/rfc2181#section-11 is still in effect

which means binary fun

still LDH label is what you usually want to see on the wire, and underscore labels of course

https://tools.ietf.org/html/rfc5890#section-2.3.1 has a nice overview

"want" :>

again, I’m not going to dig into that now

@ c query ("🤖.zash.se", org.minidns.record.Record.TYPE.TXT) java.lang.IllegalArgumentException: java.text.ParseException: An unassigned code point was found in the input 🤖

eheehehehhee

bedtime

hmm, which is kinda strange, as the robot was added in unicode 8 and this is java 11 which should support unicode 10

or do I have that shell switched to an older JRE…

but bedtime sounds good :)