ralphmIt is a long piece based on recent discussions and took me more time than I anticipated. Plenty examples!
flow+1 for examples
wurstsalatralphm: thank you for taking the time to write this up (also +1 for :parrot:)
ralphmwurstsalat: you're welcome!
pep.It's funny because I was taking part in a discussion this morning about XMPP in general on a Japanese channel, and they were saying it's not easy to get people off LINE (which is the defacto whatsapp-like app there), whereas here in our european (XSF?) circles, most of the time I hear about Slack, twitter etc.
pep.Reading your article made me think of that
ralphmSure. Another example is WeChat, but I think most of my audience is from the so-called Western world.
ralphmI also forgot to mention Facebook Templates.
pep.<mention jid="email@example.com/ralphm"/> btw, what about occupant-id?
ralphmYou mean making it more explicit what kind of jid is referred to?
pep.no I mean https://xmpp.org/extensions/xep-0421.html
pep.It'd be nice if that was also allowed in there
pep.Not especially mandated
pep.I know some people will oppose the de-pseudonymisation
pep.Also what do people have with this "@" :x
pep.Quite annoying to see this on the wire everywhere
ralphmI'm not sure, I haven't read that in detail.
ralphmAlso curious how it'd be different in MIX
MattJpep., that's why the "proxy JIDs for MUC" idea would be slightly better, since it's a drop-in replacement for a real JID
ralphmpep.: I don't see a problem with @. It would be something people type and a client could choose to strip it with references.
pep.MattJ, yeah.. I see that
MattJNobody (generally) has to know what kind of JID it is, it's just a JID
ralphmMattJ: right, and for the rest there is disco
pep.ralphm, I see a problem with @, why would we even bother to have a <reference/><mention/> tag otherwise? Why not just put @ralphm in there and let the receiving client deal with it
pep.Client SHOULD NOT include any marker in the body for this
pep.There is no point
pep.On the wire, that is
ralphmIt could, but the thing prefixed by @ can be interpreted by a server. Maybe it has a nick registration service and allows for referencing non-accupants.
pep.Maybe then the service can also read <reference/> instead
pep.I'm going to start including @s everywhere just to make fun of that service
ralphmMy examples show that the original didn't have a reference
pep.It's about the same crap idea as 393.
ralphmLet's agree to disagree on this point.
pep.You agree that this is a character that carries meaning, no?
pep.I mean essentially that's the goal
ralphmBy the way, the @ might also serve as an explicit marker to notify whoever is mentioned, as apposed to unprefixed strings that happen to also be a nick. Like someone having a nick 'nick'.
pep.That can be done in the input format yes
pep.Doesn't have to be on the wire, again.
ralphmMy vantage point is a thin(ner) client
ralphmAnd not touching what the user typed
pep.What about them? They shouldn't have to care about semantics and throw everything in body because?
pep.Why do we even bother with <reference>, somebody remind me please
pep.Let's not take Slack as an exemple, it's an implementation not a protocol, and it doesn't try to be compatible with anything else
ralphmI think it is useful, you may disagree, and the post shoes how it could be done.
pep.Of course references are useful. I was saying that because of your loose use of "@"
ralphmI do take Slack as an example, as it is done well and we can learn from it.
ralphmSo @pep. if you don't like @'s, I am not sure what to do about it.
pep.I don't like the meaning you attach to it
pep.On the wire
ralphmI didn't. It is something somebody typed and the MUC service then interpreted it as a mention. Has nothing to do with the wire protocol.
pep."Here the MUC service marks up the original messages with an explicit link reference." wait
pep.Yes I just read that
pep.That's even more awful than I thought
pep.So yes you did
ralphmI'm sorry I broke your world. I'm a terrible person.
pep.I'm actually amazed you are seriously considering this
pep.To put it as an exemple
ralphmSeriously, this is exactly how existing services do things. It is not something*I* invented.
pep.services like? Slack?
KevIt's not even an example ralphm wrote, it came from my gist. I think getting caught up on what hypothetical service the example shows isn't the right thing here.
pep.Kev, it's just that I see this coming back often
jonas’ralphm, I’ll dump a bunch of random thoughts on your article on-list
jonas’I can’t follow xsf@ right now
Kev@pep: Because it's something easy to understand for examples.
ralphmAlso Twitter, as mentioned at the top of my post.
ralphmI think WeChat, as well. WhatsApp, Facebook, etc.
pep.ralphm, yes and as I said, they're not interoperable protocols, they don't care. they don't especially have to account for let's say, offline users that the MUC doesn't know about anymore (how would it know it has to have a reference there?) etc.
pep.Or for me using @ in a totally different way
pep.The UX in these product is particularly annoying when you just want to use @ and not highlight anybody✎
pep.The UX in these products is particularly annoying when you just want to use @ and not highlight anybody ✏
pep.But I guess that's a UI issue anyway, for this last message
pep.They still could do that and not include it on the wire
pep.Kev, also my nick is "pep." :)
pep.But I guess you can't autocomplete anymore with the @ in front :p
ralphmWell, MUC's model is rather dated, and I think we need to move on from it. I think MIX solves a bunch of that, and I always try to look ahead, while learning from others. For this I don't care about how Evil those other entities or solutions are. Something like an @-mention is near ubiquitous outside our little bubble and I think the least-surprise angle works in its favour.
pep.I'm going to repeat myself: That doesn't mean it has to be on the wire.
pep.That's my only concern
ralphmReally, it is just something somebody typed.
KevIT'S AN EXAMPLE IN A BLOG POST.
pep.With an associated meaning to it
pep.No it's not just an example.
pep.It's definitely not the first time I see it. I even mentioned it last time when there was this references discussion.
ralphmIf you don't want your service to interpret @ signs, hack it to oblivion.
pep.Of course I don't, why would I. My service could interpret <references> very well though
ralphmDo you have any other insights?
jonas’sent my feedback on the list
ralphmAlso, I am a bit done with negative attitudes.
ralphmSo, sorry if I was a bit harsh, pep.
jonas’I’m gonna re-state it publicly: Thanks for taking the time for the blog post, I think it’s very valuable. My mail on-list is concise and short to save everyones time, but there needs to be time for praise for work done, ralphm.
Ge0rGralphm: thanks for taking the time and moving things forward!
pep.fwiw I have not much to say about references in the article, that looks good.
pep.I know some people were not particularly fond of the mandatory <reference> for SIMS, but in this case it makes sense to me. I guess having SIMS being used instead of oob as it currently is could not require it, though?
ralphmYeah, my thing with oob is that it is very unspecific.
pep.Sure. I'm talking about SIMS specifically, I'm not fond of the current practice
ralphmUsing a jingle file allows for thumbnails and hash references and titles and descriptions, etc.
ralphmI suppose you could also have a naked one, without body and without the references wrapper
ralphmIf you just wanted to send a picture
pep.Yeah, that's a concern I've heard multiple times
Ge0rGralphm: this is a major use case
pep.Re Jingle, there's no URI format atm right?
pep.Or is there?
Zashralphm, do you by any chance have a source format for that post publicly anywhere?
ralphmZash: not automatically, no. But I uploaded the source for this post here: https://ralphm.net/~ralphm/tmp/2019-09.xml. I hope you can appreciate it.
Ge0rGlet's bikeshed about the use of XML as a source format!
ralphmNot just any XML format. It is actually very much derived from DocBook XML
ZashIn this case it doesn't reduce the effort in turning it into epub
ZashDocBook enough that pandoc can read it?
ralphmIt does. You can use pandoc with docbook as input format
ralphmBut you'd have to fix the custom additions
Ge0rGrecently successfully converted a PDF ebook into epub, and even was able to remove the nasty-watermark-on-each-pdf-page with sed.
ralphm, hi, someone friendly has linked me your post on @mentions. i remember a certain discussion in the gajim chatroom >10 years ago. gajim at the time was highlighting the user if any part of a message contained the user's nickname (iirc). so if someone had a nickname of "kate", someone typing "skateboarding" would trip the highlight. gajim changed that to match a fixed word (iirc it was '\bkate\b'), and then people started complaining that declension happens (e.g. "kate's"). do you think you could make @mentions somehow work with that?
Dele (Mobile)has left
oh, hi jonas!
ralphmjonas’: you scared from my log source?
Ge0rGwhat are you, a RTL modifier?
jonas’, noone will read what you wrote. your nickname is empty, that baffles everyone
that would be impolite… 😛
Ge0rGjonas’: looks like it's actually http://www.fileformat.info/info/unicode/char/00061C/index.htm
ralphmI don't see anything, nor do our logs? http://logs.xmpp.org/xsf/2019-09-09
jonas’if only we had our stuff pinned to a single version of Unicode✎
Ge0rGjonas’: nice how your text is RTL formatted :P
jonas’if only we had our stuff pinned to a single version of Unicode everyone agrees on ✏
Ge0rGpasting cropped yaxim screenshots into yaxim makes my head spin
ralphmYup, Conversations gives up on this. Nameless RTL person, I read your message through the screenshot above, but your unique setup triggers bugs in several clients and will make discussion very hard. If you can it might be good to write a reply on the firstname.lastname@example.org mailing list.
Ge0rGralphm: triggering bugs in implementations is actually a Good Thing™
pep.Zash, so logs ignore it but MUC lets it pass?
ralphmWell yes, it is surely a nice test case
Ge0rGpep.: I've actually copy&pasted it from the http log
MattJpep., it's in the logs
Ge0rGpep.: it's just.... _invisible_!
pep.Sorry I was reading ralphm above who said it wasn't
MattJThough it might not look that way, since there is no nick rendered
ralphmAh, I see now
linkmauveI can read it in the logs just fine.
Ge0rGlinkmauve: you can read it?
MattJNice way to make the logs look like someone said something they didn't
Nameless RTL personmy job here is done, i guess
ralphmNameless RTL person: haha
Ge0rGNameless RTL person: please meet my friend, 🤖
linkmauveGe0rG, yes, it’s present in the logs.
Ge0rGlinkmauve: that's not what you said
linkmauveI can read it there.
Nameless RTL personi remember pasting 4MB of text into a status message and crashing all the psi clients out there. that was fun
Ge0rGlinkmauve: how can you read it if it's invisible?
ralphmNameless RTL person: in any case, there's differing opinions on whether a MUC service should do such interpretation. I do think that an explicit marker in front of the mention, whether processed at the client or by a service, helps disambiguation.
Nameless RTL personi assume it's not an important matter whether the @marker works for some unusual nicknames, either?
ZashWhy doesn't resourceprep normalize eat it, whatever it is?
ralphmNameless RTL person: like RTL markers?
Nameless RTL personyep.
Nameless RTL personor, let's make it simpler, spaces in nicknames
Nameless RTL personor one of my favorites: combining characters vs. precombined characters, typed by different people in different way
ZashPretty sure those are normalized at least
Nameless RTL personwithin message bodies too?
DanielZash: not if you let the muc server do the mention
DanielWhich is the point Nameless RTL person is trying to make I guess
ZashMyeah I don't believe in that
DanielHowever I see ralphm blog post only as an example for references
ralphmI assume existing implementationa just do prefix matching as main heuristic. And give up with"weird" stuff like RTL markers.
DanielNot as a general recommendation that all mentions should be server side
ralphmHaving followed Slack for quite a while, I believe they initially did server side mentions (only) and then added client side support.
ZashConverse.js does something
pep.Indeed. It uses <references type='mention'/> and strips the "@"
ralphmMy mail to standards@ shows the alternative (for links, but would work for mentions just as well).
Link Mauvehas joined
ralphmI still think that typing an @, v.s. not, has an implicit request for notifying the mentioned individual. I wonder if that should trigger explicit server side notification, rather than client side highlighting, esp. with offline mobile clients and Push.
pep.ralphm, note that I never disagreed on this ^
Danielralphm: your muc push could also parse the reference (instead of jumping on the @)
Nameless RTL persontbh, i'd feel uneasy if someone used my nickname and i wasn't highlighed, whether there was an @ character before my nickname or not
Nameless RTL personit would feel as if someone talked behind my back
ZashNickname registration in MUC is a thing
ralphmDaniel: I mean that if you have a client side generated mention, the server could explicitly notify / wake up the recipient. Maybe with a special out-of-band message.
ralphmBy the way, example 2019-09-02-3 shows client side mention.
ralphmNameless RTL person: services like Slack let you get notified for user defined keywords.
ralphmI usually set that up with my nick, name, and 'xmpp'.
pep.Nameless RTL person, your client could very well get over this and _also_ highlight you if you so chose, by parsing body. But that's a choice of the receiving client, and I'm fine with that
Nameless RTL personso do xmpp clients. but in the xmpp world you may have different nicknames in different chatrooms, etc.
Nameless RTL personso the client must be smart enough to allow different hl words for different chatrooms
Nameless RTL personand then the pain is on user to manually configure it
DanielAnd that's why we can't have nice things
ralphmI like that in MIX, much like Slack, is decoupled from the (proxy) JID.
Nameless RTL personis this place using mix?
ralphmI think that especially for group services like those hosted by the XSF, service wide nick registration would be a good thing.
ralphmNameless RTL person: no
Nameless RTL personstill, thanks to federation, even with registration, the nicknames can be different within a single client's opened chat windows
ralphmYes, for sure
ralphmBut highlighting $current_nick should be easy.
ralphmAnd separate from that server-assisted notification would be a thing that could be implemented.
Nameless RTL personyeah. so if the receiver client's already implementing it, why bother with the server doing it too?
ralphmYour client might be offline (Doze mode or iOS equivalent). Having server support for this allows for waking up such clients.
Nameless RTL personbut if it's a custom highlight word, it won't
Nameless RTL personinconsistency
ralphmEspecially in the context of MIX, where you are always in the room, even though you have no active resources.
ralphmNameless RTL person: you could register custom highlights with your server.
ralphmAnd finally, if you get mentioned in rooms you're not in.
Nameless RTL personok, that would be nice if there was a subprotocol for that
ralphmNameless RTL person: let's say I've thought about this stuff for a while
Nameless RTL personi guessed so, this blog post is quite thoughtful
Nameless RTL personin essence, you'd like to move more of muc complexity onto the server. that's something i can empathize with
Nameless RTL personhowever, having the api between the thin client and the server be a plaintext api, as opposed to xml, feels wrong in the context of xmpp…
ralphmWell, not just for MUCs. In fact, I think we've come to a point where we need a lot more server involvement to match functionally in other services. That's why I believe something like MIX is better equipped for that world. Another topic is voice/video calls.
Nameless RTL personmoreover, a plaintext api which the user types themselves, making it more difficult to provide a different type of ux than just a text field, if it's desirable within the client's requirements
ralphmNameless RTL person: sure, having clients mark up stuff is very useful
ralphmBut the example of link references shows the two extremes. When mentioning a URL, do you want your client to go and fetch the page, scan for meta tags, craft a format for representaion, and only then send it (or maybe later as self-fastening) or let the server do that for you?
Nameless RTL personeven more, a plaintext api which is not discoverable by the client. or are you going to make it discoverable whether mix/muc adds annotations automatically or not?
ralphmI would definitely, yes. With opt-in/out for your own messages.
Nameless RTL personmaybe. if i know that the mix/muc itself can't access the site i link, and my thick client can, then i would do so
ralphmNameless RTL person: yes, you could still, or course. It is not an exclusive choice.
ralphmBut having worked on a (closed) XMPP platform, putting it in the server makes it a lot easier.
ralphmIf you then have thick clients, you see them already having marked up things and leave it alone.
Ge0rGIf your options don't have options, you're doing it wrong!
Steve Killehas left
Nameless RTL personto me it slowly starts looking like privacy lists, but i'm fine with that
ralphmNameless RTL person: privacy lists were hard because it made routing expensive. I think this kind of thing is different.
Nameless RTL personso, let say, my thick client, when connecting to a mix/muc, could say "i can do references alone, please don't mess with my messages", and my thin client could say "help me, mix/muc, you're my only hope". a per-session setting would look nice, i guess
ralphmI'd probably use a disco feature for it.
Nameless RTL personwho'd disco whom?
ralphmThe room/service would disco you
ralphmIt does so anyway
Nameless RTL personthe only worry at this point would be the observable inconsistencies in behavior between messages from different clients. but xmpp users should all be used to that anyway, i guess
Nameless RTL personi see
ralphmI switch between desktop and mobile all the time
Steve Killehas joined
Nameless RTL personok. would that work in 1-1 chats too?
Nameless RTL personthe job of implementing the annotations would have to be shared between the mix/muc implementation and the, i don't know how it's called… core server?
ralphmI don't see why your own server couldn't mark up stuff for you
Nameless RTL personwould the recipient's server mark things up if the sender's server didn't?
ralphm(if you want that)
ralphmI'm not sure. In MUC, there is a separate entity in the conversation, from which annotations could come.
ralphmIn 1-on-1, you don't have that, so I'd expect only my own server touching my messages and sending them from my bare JID.
pep.Validations the source jid for references won't be a requirement?
pep.Though MUCs can also impersonate you if they want to..
Nameless RTL personright, this third-party annotator service would have to be trusted
ralphmpep.: access control is definitely a thing, and feature dependent
ralphmE.g. reactions can come from anyone. Edits not so much.
ralphmAn alternative is not actually having one-on-ones, but all your conversations as rooms. I think BuddyCloud did this, as does Slack.
ralphmThis also allows for smart bots that suggest movie times when you mention The Lion King.
ralphmAnd yes this is invasive, but there's a value proposition there.
Nameless RTL personi guess i wouldn't mind. my primary client does that anyway, mostly
ralphmSure. I think there's a limit to what you want to stuff in your server, though.
ralphmBut maybe a model where everyone runs their own server is compelling in the long run.
Nameless RTL personserverless messaging isn't used anyway, i think
Nameless RTL personthe last time i tried doing so, i got enough spam to leave the xmpp world for close to ten years
ralphmThe thing is, if you don't trust your server, there are suddenly a lot of things you can't do.
Nameless RTL personi want to trust the server in the capacity of routing messages correctly, not much more than that
ZashU+061C ARABIC LETTER MARK
Nameless RTL personhi Zash!
ralphmTake those emoji reactions. If all the exchanges have e2ee, you can't do summaries efficiently.
Link Mauvehas left
Nameless RTL personmy perfect setup would be a server whose only job is to route messages within a federated network, a thick "xmpp client" set up on my private always-on account somewhere, and a thin non-xmpp client connecting to that thick client and only do UX
ralphmHm. I'd probably shift the thick bits to the server and just use thin clients.
Nameless RTL persona bit like irc server/irc bouncer/irc client setup used to be popular
ralphmEven for annotations, by server could intercept outgoing messages and send extra stanzas.
Link Mauvehas joined
Nameless RTL personthe bouncer part would implement the hard bits of the client, like maybe encryption, annotation, etc. and would run either on my local machine, or somewhere in the cloud under my control.
ralphmI have at some played with the idea of bare-account-jid-components
ralphmWhich is mostly that
Nameless RTL personand if we could deal away with JIDs used as personalities, that'd be perfect. they're good for routing, but not much more than that in my opinion
ralphmA special client connection that doesn't bind a resource and can manipulate traffic.
Nameless RTL personbut at that point it wouldn't be xmpp anymore
ralphmI don't have a very strict concept of what can be called XMPP.
Nameless RTL personnot interoperable enough with clients implementing 3920/3921
ralphmIn fact, you can totally do XMPP Core only.
ralphmThere are situations where you'd only do s2s, not c2s, e.g. to federate an existing system with XMPP.
ralphmFrom the other side, you wouldn't be able to tell.
Nameless RTL personoh. then i'm happy to be informed that icq was an xmpp client thanks to transports
ralphmI've implemented and run services with an XMPP PubSub interface that didn't support the publishing and node creation bits of the protocol. Nodes magically existed as a function of business logic.
Nameless RTL personi see.
ralphmNameless RTL person: well sure, the transports were basically IRC etc. clients that magically made other IRC users have a JID.
Nameless RTL personthen i used wrong name.
ralphmI am a strong believer in the protocols. I don't care much about the things behind the scenes.
Nameless RTL person"then it wouldn't be xmpp instant messaging anymore"
Ge0rGNameless RTL person: if you create an identity model that's not based on xmpp JIDs, suddenly many xmpp features stop making sense.
Nameless RTL personGe0rG, exactly what i meant by that sentence
Ge0rGIf you want decentralized identities, you end up with public keys being user identifiers, and then every message must be a signed (+ encrypted) blob and routing follows some overlay structure.
Ge0rGAnd then xmpp is only a hindrance
ralphmGe0rG: yup, I agree with that. But there's no reason why you couldn't have a thing that sits with the bare JID and manipulate incoming and outgoing traffic to assist regular clients.
Ge0rGYou could of course use the xmpp message format inside the encrypted blob, so that you can have all the client side XEPs
Ge0rGralphm: but the bare JID is owned by your server, not by you!
Ge0rGAnd the server is mostly trusted
ralphmIf my server allows for a special API, e.g. with a kind of client-component, to act on behalf of my bare JID, why not?
Nameless RTL personi'd be fine with user-visible JIDs, as long as there was a metaprotocol stating that those several JIDs are all me, other people can discover these other JIDs easily, and normal users could be made oblivious to their existence
Ge0rGralphm: what would that give you that can't be given by the server directly?
ralphmAlways on scriptability, and other stuff you want to have, your server might not provide, and offloads clients.
ralphmBut annotations could be one example.
Ge0rGNameless RTL person: so you want to use xmpp as the routing layer for a p2p protocol based on a cryptographic identity?
Nameless RTL persona simplest solution would be a simple discovery protocol of "how can i contact you in other ways" + crypto signing of auth requests
Nameless RTL personand keep all the rest of xmpp intact
Ge0rGNameless RTL person: then it's just a very sophisticated mechanism to exchange encrypted blobs.
Ge0rGNo benefit on top of protobuf over DTLS with TURN
pep.not reinventing all the things? If you can use client XEPs for example
Nameless RTL personin this sense, xmpp itself is just a very sophisticated mechanism to exchange xml on top of tcp
ralphmOh, if you want Jingle-negotiated p2p XML Streams, why not?
Nameless RTL personi've never written anywhere i want p2p or jingle
ralphmMuch like Local Link Messaging
ralphmNameless RTL person: true
Ge0rGpep.: yes, but you need to map your cryptographic identity scheme to faux JIDs to make most client XEPs work
pep.Ge0rG, something like <fp>@domain? That you could change at will
Ge0rGNameless RTL person: p2p is just the consequence of decoupling your identity from your JID
Nameless RTL personexcept by having actual xmpp servers, i don't need to do routing, offline storage, etc.
pep.Ge0rG, that :)
Ge0rGWith onion being the verbatim name of the used cryptographic identity protocol
Ge0rGNameless RTL person: which server would keep your offline messages if you have three different JIDs?
Nameless RTL personall of them.
Nameless RTL persondepending on which on received a given message✎
Nameless RTL persondepending on which one received a given message ✏
Ge0rGAs if deduplication wasn't hard enough already
Ge0rGNameless RTL person: so if one of them fails, you only receive two thirds of your backlog?
Nameless RTL personyep.
pep.(which is already the case anyway)
pep.(I mean, if your server fails, you receive 0/1 of your backlog)
Nameless RTL person⅔ > 0
Ge0rGCongratulations! You've created a protocol that combines the drawbacks of xmpp with the drawbacks of p2p!
Nameless RTL personthank you, i'm very happy
Nameless RTL personit's still better than not having any means to move accounts between servers in case of problems, or in case of, let say, just being disappointed with the server operator
Ge0rGNameless RTL person: ask pep. about Moved.
pep.True, that helps with <moved/>. And that's kind of where changes on that XEP are leading anyway..
ralphmWell for what it is worth, running my own server, e2ee is overrated at best and a pain at worst.
pep.ralphm, lots of people in this room specifically agree with you. Not so many outside of it :)
Ge0rGralphm: welcome to the club of OMEMO rejects.
Nameless RTL personi talked to pep. about it, yes. i don't find it a good solution
Nameless RTL personbesides, what's wrong with just stating my other JIDs? i can make a contact in my smartphone having multiple phone numbers and it works
ralphmpep.: Is moved more than https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-gone with forwarding address?
ralphmpep.: yes I am aware
Ge0rGNameless RTL person: your contacts are managed by you. Your "friend's" alternative JIDs are managed by them
ralphmpep.: I also have issues with crypto-currencies.
Nameless RTL personyeah, and we're in an era where computers are supposed to help managing things up
pep.ralphm, yes it's more than <gone/>. We discussed it a few times, I could grep through the logs, I don't remember much off-hand
Ge0rGralphm: the biggest issue with Moved is that all mechanisms it provides are ephemeral
ralphmpep.: yeah, I vaguely remember. Happy to pick that back up at some point.
pep.What Ge0rG says
pep.You can very well make it so the current <moved/> is changed minimally and serves some part of the requirements
pep.But there's a demand for more and that would likely require crypto identities
ralphmGe0rG: I added node delete + forwarding address notification, to cover that case with nodes-as-things, and implement moving 'things' between websites, habing all subscribers rewrite their references
Ge0rGBut you'd need pep to persist the tombstone
pep.Ah yes the tombstone. That you should keep on the old server and that your contacts should keep on their servers as well..
Nameless RTL personhas left
pep.Anyway. "Not today!"
Ge0rGralphm: when I first looked at Moved, I was under the impression that all it needs are two or three minor changes to work in today's environment. But it turned out to be a bottomless pit
DanielDo I have to send presence to a muc before I create/configure it over iq?
pep."has left the room due to an error (Kicked: jid malformed)" oops?
flowanother testcase for the jid corpus \o/
pep.Zash, which ones of your clients got kicked btw?
pep.Zash has left the room due to an error (Kicked: jid malformed)
ZashGot an exact timestamp?
Zash... got it in UTC+2?
pep.what, my vps is in Japan, still..
ZashThat's in the future :|
ralphmIf Zash can't do substractions, why are we letting him write code?
ZashIt's late and I'm tired
pep.I got confused by tmux showing me the current datetime
Link Mauvehas left
Zashralphm, you know how brains are really terrible at basic math, while pretty good at extremely complicated tasks like walking without falling over?
pep.(Yes that's a nested tmux)
ralphmZash: I'm not sure if that's true at all.
ralphmIt is likely dependent on how often you it.
ZashHush, I read it on the Internet, it must be true. And then it's totally sensible that I'd be terrible at math while being good at telling computers to do math.
2) If a string contains any RandALCat character, the string MUST NOT
contain any LCat character.
3) If a string contains any RandALCat character, a RandALCat
character MUST be the first character of the string, and a
RandALCat character MUST be the last character of the string.
ZashAnd the MUC here uses libidn
Zashjonas’, TL;DR rejecting is correct?
jonas’Zash, probably, I’d have to check the categories of the involved characters
ZashU+061C ARABIC LETTER MARK
U+0078 LATIN SMALL LETTER X
jonas’u+061c is invalid because it’s unassigned to my validator
ZashHm, is that going to bypass the rule forbidding empty nicknames;
jonas’Zash, but yes, if we used a newer unicode version: U+061C is AL, thus RandALCat as per StringPrep, U+0078 is bidi category L, which is LCat, which MUST NOT occur in a string with RandALCat
ralphmOne of the issues might be that resourceprep is defined using Unicode 3.2 and this codepoint is 6.3.
jonas’fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell
jonas’ralphm, yeah, that’s what I meant when I said "u+061c is invalid because it’s unassigned to my validator"
jonas’Zash, so, yes, rejecting is valid, but only if you also reject U+061C on its own
jonas’otherwise you’re rejecting based on the wrong reasons, at least if you’re using resourceprep from RFC 6122 as basis
jonas’(if you’re using PRECIS, I don’t know)
ralphmProbably something is using newer tables for normalization.
ZashNot using PRECIS
ZashNeither of the two libraries I can currently choose between has PRECIS
jonas’Zash, then something is wrong on your end if it allows U+061C, but not U+061C U+0078
Ge0rGSo the logical consequence is to reject strictly on c2s and less strictly on s2s?
ralphmAlso no 🥓 or 🦒 in resources
jonas’Ge0rG, I think that’s the only sane way forward
Ge0rGSo you can't get kicked because of somebody else
pep."Ge0rG> pep.: yes, but it doesn't. What now?" You also validate and reject it (send message errors)
ralphmGe0rG: why wouldn't a server reject incoming invalid JIDs on s2s?
ralphmThat other server is clearly not checking properly
ZashProblem: Allowing unassigned code points has been the default (probably unintentionally) too long. Everything will be painful.
Ge0rGralphm: because what happened to Zash in this MUC today
ralphmSo xmpp.org is at fault
ralphmIt apparently accepted the bad jid and then also sent it on?
ZashIn turn because libidn and relaxed defaults.
Link Mauvehas joined
flow> jonas’> fun fact: that’s the kind of stuff which may change breakably between unicode versions, which is why PRECIS will be all kinds of interop hell
Isn't this only true if we accept unassigned codepoints?
ZashPostulate that we do.
Zashflow, jonas’ stated that there may be things that normalize to different things between versions
flowunicode standard versions?
flowPotentially yes, but I'd expect that to be very rare. Could be wrong though
Zashflow, also, as I mentioned earlier, accepting unassigned codepoints is the default in libidn and thus prosody for some reason
Zashand probably other users of libidn
flowSomething else ftw
Dele (Mobile)has joined
flowJust reading ralphm blog post. So 2019-09-02-14 attaches to 2019-09-02-11, but since -11 has been corrected multiple times, it actually attches to 2019-09-02-13?
ralphmflow: as currently envisioned, attaching is solely to the original stanza.
Dele (Mobile)has left
ralphmBut I agree this part is something needing more thought.
ralphmIt might be useful to specify a second id, in this case the edit
flowwell that id you already have, the <stanza-id/> of the stanza performing the edit, no?
ralphm"apply to 1, as modified by 2"
ZashWave but not quite?
flowralphm, xep372 begin/end are zero indexed
ralphmBecause it depends on semantics of the thing being attached.
flowit appears you use 1-index in your examples
Dele (Mobile)has joined
flowYeah, I also think how much we potentially could learn from wave
ralphmflow: oh, I'll check that tomorrow
flowA look at the wave spec couldn't hurt
ZashProtobufs, just like Ge0rG wanted
ralphmE.g. for reactions you generally apply to the 'message' irregardless of edits.
ralphmBut references break with edits.
ralphmYeah Ge0rG and stanza versioning has come up a few times in private discussions I've had in this.
Ge0rGI was not involved in any backroom deals!
flowI've just read up on U+061C, it's assigned since 2013 and in the Cf category, which means it is a control character and hence disallowed in resourceparts
U+061Cyay, protobufs, this NIH thing known only because google invented it
ZashIt also magically solves all protocol problems
pep.Isn't that just a serialisation format? (I've never actually used it)
U+061Cindeed. seen a bad case of hyperprotobufoxia before
ZashWhy does XMPP even exist when protobufs can do all that?
ZashOr was it MQTT?
Zashpep.: I haven't used it either, which makes me qualified to describe exactly what it is. And I say "versioned structs".
U+061Cpep., yes, it's a serialization format that's mediocre at what it can express (lots of great prior work) with somewhat good tooling (something that, i think, was the actual breakthrough of protobufs)
pep.So it's like JSON?
U+061Cmore strongly typed
ZashIt's like C structs
ZashWith version numbers!
U+061Cand not self-describing, ie. you can't parse a protobuf binary encoding unless you know the spec used to generate it
U+061Cand not self-terminating either, ie. if you have a binary message, only part of it being a protobuf, you need to figure out where it ends on your own (e.g. sending length separately)
ZashSo you write some C struct definition and then run some tooling that spits out tons of boilerplate for whatever language.
U+061Cboth of these result in shorter messages though
ZashNot being self-describing will do that for you
U+061Cchat states in this webchat thing are so annoying
U+061Cit's not a bad tool, but those google folks could have instead support an existing standard instead. that's why it's NIH
ralphmflow: but it being unassigned in Unicode 3.2 makes the rest of your argument moot anyway?
ralphmOr are you looking at Précis?
ralphmSo I guess 🥓 being a So makes it acceptable for a resource?