vanitasvitaeto be sure, IM NG was the next iteration of "Message Routing", right?
vanitasvitaeLike, the plans to ditch full jid routing from last years summit?
MattJvanitasvitae, correct
vanitasvitaealright.
vanitasvitaeAnd the reason for wanting IM NG is exactly?
MattJhttps://xmpp.org/extensions/xep-0409.html is the initial proposal
vanitasvitaeWhat does it solve?
vanitasvitaeah, thanks
MattJThe routing rules in RFC 6121 were made before Carbons, MAM, etc.
jonas’vanitasvitae, several things
MattJWe layered Carbons and MAM on top of them to try to fix the gaps with e.g. having multiple devices, sometimes offline
jonas’1. if you have IM-NG, clients are kind of responsible for declaring if their message needs to be broadcast and archived (by sending to bare JID), and servers are left with less to guess
jonas’2. it removes some "undefined behaviour" wiggle-room from RFC 6121 regarding handling of bare and full-JID messages. specifically, full-JID messages will never be re-routed to a different full-JID under IM-NG, and bare JID messages will always be received by all (online + MAM-capable) resources
MattJThey solved 80% of the problems, and added complexity for servers (and clients) that have to handle all the interactions between these different things
vanitasvitaealright, thanks for the clarification 😉
jabberjockehas joined
MattJIM-NG is essentially and XMPP 2.0 thing without throwing away all the good bits
MattJIt will make life easier for developers
dwd@dave.cridland.netYeah. Just listen to how much easier this is.
vanitasvitaeI can tell 😛
ZashJust YOLO flag day it!!!eleven
thdoukhas joined
pep.(I'm a bit lost around that re minutes)
vanitasvitaeYeah, me too 😀
vanitasvitaeSo basically the discussion is about uncertain rules for routing of error messages, right?
vanitasvitaeLike, edge case handling?
dwd@dave.cridland.netYou're welcome to speak aloud. More voices would be useful here I think.
MattJThe current rules are not uncertain - error messages for e.g. delivery errors simply go to the sending device only
vanitasvitaemakes sense to me.
debaclehas joined
pep.I'd appreciate if somebody(tm) with a bit more understanding of the situation could have a look at minutes on this topic
MattJThe reason it's complex is purely because we need backwards compatibility with all the existing clients and servers
thdoukhas left
MattJOnce we phase out Carbons and the various hacks around it, things will be a lot simpler
pep.*shocked*
jabberjockehas left
jabberjockehas joined
debaclehas left
debaclehas joined
hantu.schas joined
Intosi6121 SP2
pep.Service Pack 2 ?
vanitasvitae"Redstone Update"
larmaSomething unstable you probably don't want to start using for the first year?
hantu.schas left
vanitasvitaeStrange, today there are so many people named "Angie" around...
vanitasvitaeKev keeps repeating "I am Angie too" for some reason...
vanitasvitaePretty sure he is lying
Kevsighs
Intosiinserts GIPHY of Picard facepalm
hantu.schas joined
jabberjockehas left
jabberjockehas joined
thdoukhas joined
vanitasvitaeThe internet is asking if there are any plans to "secure metadata".
vanitasvitaeI guess apart from e2ee there is maybe the sender-less messaging on the agenda, right?
goffiI've been to Froscon already, it's open to non german, and very nice meeting
goffi(and nice food)
vanitasvitaeI found it less community oriented and more business focussed than FOSDEM.
MattJvanitasvitae, my personal opinion is "no" - there are other solutions that already do a better job at hiding metadata
MattJThey make a certain set of compromises to achieve that
thdoukhas left
adiaholichas left
flowI think we can, besides taking care of the low hanging fruits right now, only start consider securing metadata after the majority of messages exchanged in xmpp is encrypted. One step after another
MattJflow, and how will the server know where to deliver messages, presence?
flowMattJ, I am not sure if I expressed myself where well as I think you may misunderstood me
flow*very well
flow*after the majority of the payload of messages exchange in xmpp
vanitasvitaeyou could at least hide the recipient from the sending server
MattJvanitasvitae, and how would it know where to deliver to?
vanitasvitaewell, it obviously has to know the domain jid, but not the exact recipient
vanitasvitaebetter than nothing
vanitasvitae 😛
MattJvanitasvitae, which goes against the "it's good to run your own server" model that I'm pushing for :)
flowI think it is not productive to put much effort into metadata encryption while we do not even encrypt a majority of the payload
MattJbecause you'll never guess who a message to the domain "matthewwild.co.uk" may be destined for!
vanitasvitae😛
MattJYou /can/ hide metadata, but it requires a drastically different protocol architecture to achieve that (e.g. something like a gossip protocol)
flowAlso if you are afraid that metadata is an issue, then you probably should not use XMPP at all. That said, if we can protected metadata easily, we sure should consider it.
dwd@dave.cridland.netYou could do onion routing over XMPP, of course.
MattJYou can *already* do XMPP over onion routing
dwd@dave.cridland.netYes, the other way aorund.
IntosiSo a hyper onion?
flowI think you lay every other protocol over xmpp, like vuvuzela.io, how interoperable that would/could be is another question
winfriedAnd now something totally different... Sunday morning I will be presenting on the XMPP extensions. What extensions do you think I definitely should mention to the Fosdem audience?
pep.What kind of extensions are you presenting? What's the goal?
pep.Funny XEPs? Unused XEPs? Useful XEPs?
pep.(And what for)
vanitasvitaeCompliance Suite 2020 😉
pep.Yeah I was gonna say
winfriedMy goal is that I discovered that developers considering XMPP find the idea of a modulair standard hard to grasp, so I want to do 2 things: explain how the extensions work (as process, idea, not technically) and I want to mention some nice examples on the way.
winfriedCompliance suite will definetly be mentioned, because it is a good starting point for many usecases
MattJwinfried, there are three things that people who vaguely know XMPP are concerned about: 1) too many XEPs 2) stuck in the past 3) fragmentation (different clients implement different XEPs)
MattJSo answers are: 1) C Suites / deprecation of old XEPs 2) new XEPs are being submitted and implemented almost every week 3) C Suites aim to solve this
jabberjockehas left
jabberjockehas joined
pep.(of which 3) is definitely a feature of XMPP.. just that these people don't get it :x)
pep.Sorry mismatching parentheses
MattJwinfried, heh, someone just linked to your talk in a different MUC :)
vanitasvitaeI'd also point out that even if you do some centralized service, XMPP is a good choice as there is already a tried and tested codebase + implementations and building on top of that with custom stuff is very easy.
vanitasvitaeNot that I'd suggest doing centralized stuff, but still
vanitasvitaemany devs want to
thdoukhas joined
winfriedMattJ: good points, I'll make the C-suites more dominant in my talk
winfriedMattJ: what MUC?
MattJwinfried, conversations@conference.siacs.eu
adiaholichas left
winfriedMattJ: thanks, can't join... ;-)
jabberjockehas left
jabberjockehas joined
winfriedvanitasvitae: yeah, I would also like to mention some specific usecases, like real time text (which is very useful for communication with deaf people)
vanitasvitaeyeah nice idea
winfriedSo this is your chance to upvote your great but very specialist XEP for a great exotic usecase ;-)
thdoukhas left
moparisthebestvanitasvitae, I've thought about the "hiding metadata" thing a bit, the problem being it's only easy 1 way (hiding the recipient from your own server), hiding your JID from the recipients server requires something totally different and much harder, and then there is the roster problem :'(
moparisthebestI still think it's likely worth doing
winfriedmoparisthebest: it would be quite trival to make an onion routing component for XMPP and turn the XMPP network in a onion routing system....
moparisthebestthat might be the way to go to solve both ways the same, then you just have to hide the roster from your own server and you've got yourself a complete system :)
jabberjockehas left
jabberjockehas joined
vanitasvitaeCoffee break after this?
flowIs there any reason why we should give up the possibility to implement bind2 or sasl2 indepentently from each other?
jabberjockehas left
jabberjockehas joined
hantu.schas left
vanitasvitaecoffee!!!
SyndaceIf someone knows how to get fresh air into this room, please make it flow
pep.(ha ha?)
nycoyes, it stinks
vanitasvitaeyeah flow, go for it!
hantu.schas joined
flowI have opened the window in my office, does that help?
vanitasvitaeYou have to also open the <stream/>
KevCould you take some of the fresh air and publish it to pep. please?
thdoukhas joined
thdoukhas left
KevAre the "IC" trains any different to the "S" trains for my train ticket I bought at the station machine?
Danielsince the ticket machine doesn’t let you choose between the two i always assumed the same ticket is fine for both
KevTa.
jabberjockeAny plans for evening?
MattJSleeeeeeeeep
IntosiFood as well. There will also be drink, I suspect.
eevvoorhas joined
Kevhas left
goffiMovim has its own sticker sets already
MattJgoffi, bundled? hosted somewhere?
goffiInitially I think it was shared with BoB, but I'm not sure nowadays, maybe SIMS
nycoyes, goffi based on XHTML-IM?
goffinyco: Initially, but I think it's SIMS now
goffinot sure, to be checked with edhelas
ZashBut does it have a sticker store?
goffialso about file size and directories, we have already all that with Jingle, I have a component doing this for file sharing
nycoand themed emojis for announcers
Link MauveNo, Movim ships them and it’s AFAIK not extensible.
goffiZash: no store I think they are bundled with the software
Link MauveHe sponsored the drawing of the packs it ships.
goffimost of those problems are the same as with avatar
goffiso it would be nice to have some kind of factorisation there
goffi(different sizes, image formats, etc)
vanitasvitaeA Security Consideration would be that sticker sets are external data, so the processing must be secure
DanielYes. Also either leaking your ip or your jid everywhere
DanielThat's why having your server copy them over might be interesting
Tobiashas left
Tobiashas joined
goffiI think that we actually need a server side HTTP proxy that user can request with some kind of identifier, instead of something specific to stickers or anything else.
jonas’I think mastodon-ish-things have something similar
moparisthebestI get the impression other protocols don't really care about leaking private data all over the place
ivucicahas joined
thdoukhas joined
vanitasvitaewell, centralized systems dont have this issue at all
moparisthebest(not saying XMPP should be like that, the opposite)
goffiAbout (X)HTML, please take into account that Movim and SàT are doing blogging, and we already manage a large set of HTML (i.e. not only XHTML-IM). We should probably have a XEP describing good security practive with that.
zashhas joined
SyndaceI think immutable sets and and copying the set to your own server is the way to go
Syndacebut happy to discuss that later/on list
vanitasvitaefor privacy yes
vanitasvitaefor flexibility no 😀
goffiI don't get everything that MattJ is saying :-/
jabberjockeIntosi:
> Food as well. There will also be drink, I suspect.
At hotel or other place? Just arrived to Brussels
MattJgoffi, the words or the meaning?
nycogoffi : 3rd point, he forgot :)
ivucicaServer-provided stickers would be awesome. Well-known/discoverable pubsub node for sticker collection which lists pubsub nodes containing individual stickers?
goffiMattJ: I don't get all the words ^^.
goffiAre we willing to do a XHML only for IM, or something also used for blogging?
MattJgoffi, my words were saying that 1) clients need to sanitize stuff already anyway 2) XHTML-IM v1 was harder to sanitize because it allows and heavily uses CSS
thdoukhas left
goffioh no, here comes markdown again :(
goffiMattJ: OK, thx
adiaholichas joined
goffiMardown is not a wire format, it's handy and should be use in client, but we should use a real wire format for sharing the content.
goffiMarkdown*
jonas’oh dear
jonas’message markup all over again?
jonas’what goffi says is true
moparisthebestgoffi, why is XHTML better as a wire format than, say, CommonMark ?
goffiwhat's wrong with https://xmpp.org/extensions/xep-0394.html? I really love this one?
vanitasvitaeRegarding stickers: The internet notes that Zom (the XMPP version) also supported stickers and may be worth a look.
goffimoparisthebest: well, first it's XML, and XMPP is XML
moparisthebestthat's probably not a reason
Intosigoffi: agreed on 394.
goffibut I don't say that XHTML-IM is necessarily the best way, I really love XEP-0394, it clean, elegant, and extensible
goffiit's*, sorry for the typos
moparisthebestyou still need some specialized parser/display logic to display both XHTML and CommonMark, neither of which comes by default with XML or XMPP
Danielmoparisthebest: is this an encumbrance?
moparisthebest:D
goffiDoes anybody takes blogging into consideration, as there are only 2 clients with blogging, I have the feeling it's always ignored.
Danielso we want something like message styling but make it explict that message styling is being used?
vanitasvitae*.*
jabberjockehas left
jabberjockehas joined
goffiJust for the record, here are the complains I've made about markdown in the past (cc moparisthebest): https://mail.jabber.org/pipermail/standards/2017-October/033592.html
moparisthebestgoffi, those are all correct as a criticism against "markdown" because it's not specified, but "CommonMark" is specified
pep.goffi, I don't like 394 for what larma just said. It's leaving 393-like info in body without saying that these characters can be removed
pep.And then we're back to parsing body
pep.https://lab.louiz.org/poezio/poezio/issues/3455#note_7769 < what Link Mauve is talking about
larma^ solves the issue of knowing if it's fallback or not
goffipep.: I don't get what is left in body with XEP-0394? it's all in <markup> isn't it?
vanitasvitaeno
vanitasvitaethe original message in in <body>
adiaholichas left
adiaholichas joined
vanitasvitae<markup> only contains markers where certain formatting starts and ends
goffivanitasvitae: yes the message in <body> and markup in <markup>, that's the point
vanitasvitaeokay, I only followed with half an eye, maybe I missed something 😛
larmagoffi, the problem is that you may want to have fallback (using 393) in <body> but not display that when 394 is supported
goffipep.: vanitasvitae: I was meaning what markup is left in the <body>?
goffilarma: why do I want a fallback as long as the message body is visible by everybody? Compatible client add style, not others, what's wrong with that?
moparisthebestwhenever you send the same thing in 2 different formats/languages/whatever that opens up all those security issues that aren't practically solvable :/
goffimoparisthebest: that's an issue with legacy XHTML-IM I agree, but not with XEP-0394, the message content is only in <body>, or am I missing something?
pep.Sorry I'm not taking much notes atm as I'm taking part in the discussion actively :x
moparisthebestyep that's right goffi
goffino worries pep., and thanks a lot (and to the other) for those notes, it helps a log to understand when you're not there.
larmagoffi, the "formatting" might be an emphasize that is required to transfer the message
larmaloosing this emphasizing might change the message in some cases
goffiSorry to insist about blogging, but I think we need a XEP to explain best practices to sanitize HTML, and probably a different markup for IM
alameyohas left
alameyohas joined
goffilarma: yes, but in this case fallback can cause trouble too, be can go far with that.
larmagoffi, that's why it's complicated 😉
moparisthebestlarma, true, like if I'm quoting hitler I likely would not like anyone to think I said it directly instead :/
goffiOK so we're talking only about IM markup there, I wanted to be sure, thanks
nycothx goffi
goffi(blogging is part of XMPP, even if not IM)
adiaholichas left
goffithe issue also with markdown, is that there are billions of more or less (in)compatible parser, and developer will use the available one
adiaholichas joined
goffiso rendering may be different because markdown_js is not exactly the same as markdown_rust or markdown_js
moparisthebestgoffi, and that's not an issue if you specify CommonMark, right?
moparisthebesthttps://commonmark.org/ that one
Danieli think we can at least make some improvements to the current situation by having clients that use 393 make it explicit that they are doing this
goffimoparisthebest: if you are 100% sure that all libs used are commonmark compatible, I guess this would not be an issue, but I highly doubt that we'll have something rendered identically everywhere.
moparisthebestgoffi, so like HTML then? :D
goffiDaniel: yes please make it explicit, that one of the main issue I have with XEP-0393
Danieli mean that's a very easy fix
pep.goffi, that's not enough to me, saying explicitely you do 393
goffimoparisthebest: We have only 2 HTML rendered left, so it's not an issue anymore ;)
Danielthat has no huge side effects
goffirenderer*
pep.Parts of your message could not be markup
goffimaybe 3 with servp
goffiservo
moparisthebestgoffi, I'm saying there are plenty of HTML parsers/renderers, and none render quite the same
moparisthebesteven though HTML is a standard, same situation with CommonMark
moparisthebest393 just documents what all XMPP/IRC/email clients have been doing since forever, it never removes characters, it's fine as-is imho
goffipep.: I agree with that, and I was thinking that putting everything in <body> was not necessary anymore with OMEMO now that we have XEP-0420
goffimoparisthebest: Again, I'm not saying that (X)HTML is the best option, I'm pushing more for XEP-0394
moparisthebestalso to clarify cramming CommonMark in <body> without any indication would be awful I think everyone agrees, but as far as a specified transport, it's just as valid as XHTML or any other standard
goffiI just need XHTML for blogging (specially when importing external sources like RSS/Atom).
moparisthebestalso CommonMark doesn't solve any problems with regard to sanitization, it's a XHTML super-set, so all sanitization rules still apply (any valid XHTML is valid CommonMark)
pep.goffi, agreed, putting everything in body is not a requirement for future work
vanitasvitaeI think Marking up messages is a non-problem 😛
goffiWe should do like with stickers: a syntax server where everybody can upload a syntax parser in a home made language, so everybody can use it favorite one :D
vanitasvitae😀
hantu.schas left
vanitasvitaemarkup as a service
goffiThanks a lot for the video which was pretty good this year, and live report on etherpad, here and activityPub
moparisthebestJust upload and download webasm binaries goffi ? :D
goffimoparisthebest: great :)
moparisthebestSecure! Flexible! Trustworthy!
moparisthebestPick only the middle one
jonas’so not commonmark or anything like it?
jonas’sounds like a plan!
pep.And in 5 years everybody wants to do BBCode again
pep.markup fallback is going to be tricky
goffiexcept with XEP-0394
pep.But then maybe clients will finally understand that they have to translate the input :p
vanitasvitaeThe internet notes "I think it is important to announce to a client that the text is markdown styled. Similar to how OMEMO messages are announced as such. "
pep.goffi, 394 + fallback yes, still the same issue
jonas’goffi, '394 is meh though. I’d prefer to go back to a restricted XHTML-IM subset.
moparisthebest394 isn't bad, but yet-another markup format that no one uses etc etc, specify something like CommonMark where all the hard work is done and call it a day
adiaholichas left
adiaholichas joined
goffithe big difference with XEP-0394 is that markup is separated from body content and meaning, no other solution offers that.
goffiso if you don't support it, you still have the plain text body, without having to clean it yourself or to use any kind of fallback.
moparisthebestwhich has it's own set of problems
thdoukhas joined
dwd@dave.cridland.nethas left
goffimoparisthebest: which ones exactly? I still don't get what's wrong with that.
moparisthebest> we should kill all $race_here because they are worthless subhumans
moparisthebestexcept your client doesn't support 394, so it's not rendered like a quote
moparisthebestit's rendered like I said it
moparisthebestthat's... less than ideal
pep.I'm stuck outside, nothing at the front, can somebody open? :p
pep.all good
winfriedhas left
winfriedhas joined
goffimoparisthebest: well you have usually have context, and you'll have this issue with any markup fallback
moparisthebestit's possibly less of an issue if you just display raw CommonMark ? :/
moparisthebestmaybe raw CommonMark in <body> with a flag stating it's CommonMark, then if it is, you can safely parse/display it as intended, and if not the fallback is just to display it directly?
goffimoparisthebest: you're going with XEP-0393 then
moparisthebestthere is no perfect solution here I think
winfriedhas left
winfriedhas joined
goffiseing that we're all arguing with that for years, I guess the perfect solution if it exists is not obvious :)
winfriedhas left
winfriedhas joined
jabberjockehas left
jabberjockehas joined
Kevhas joined
moparisthebestI just suspect there can never be a perfect solution here:
1. same message, multiple formats/languages - no way to tell if they are different
2. standard non-plaintext format (XHTML/CommonMark/394) - if not supported, plaintext fallback could change meaning or be unreadable for any number of reasons
3. no plaintext fallback - well, no plaintext fallback :)
moparisthebestI *think* that about covers all the options?
MattJWhy did you italicize 'think'?
moparisthebestdid I? :)
MattJOh, you're right, it's underlined in my other client
MattJj/k of course :)
moparisthebestbold for me haha
moparisthebestman if we can solve "derive meaning from text messages" we'll really have it made
Kevhas left
adiaholichas left
adiaholichas joined
Kevhas joined
Kevhas left
Kevhas joined
moparisthebestI guess we do have a standard already to transfer thoughts/intent/meaning over XMPP https://xmpp.org/extensions/xep-0183.html
kusonekohas left
kusonekohas joined
kusonekohas left
winfriedhas left
winfriedhas joined
kusonekohas joined
debaclehas left
eevvoorhas left
thdoukhas left
kusonekohas left
kusonekohas joined
kusonekohas left
kusonekohas joined
alameyohas left
alameyohas joined
Kevhas left
Kevhas joined
adiaholichas left
adiaholichas joined
SyndaceOh, I forgot trading the taxi receipt for money today, shall we do that at fosdem tomorrow?✎
SyndaceOh, I forgot to trade the taxi receipt for money today, shall we do that at fosdem tomorrow? ✏
DanielIn the past I think I just emailed them to Guus or something
pep.ah right I'll do that as well
Syndaceok thanks, will do that
Martinhas left
Martinhas joined
Kevhas left
eevvoorhas joined
jabberjockehas left
jabberjockehas joined
jabberjockehas left
adiaholichas left
Guushas left
Guushas joined
alameyohas left
alameyohas joined
winfriedhas left
winfriedhas joined
debaclehas joined
thdoukhas joined
winfriedhas left
eevvoorhas left
Kevhas joined
winfriedhas joined
winfriedhas left
winfriedhas joined
thdoukhas left
Guushas left
Guushas joined
winfriedhas left
winfriedhas joined
winfriedhas left
nycohas left
winfriedhas joined
nycohas joined
winfriedhas left
winfriedhas joined
Kevhas left
eevvoorhas joined
SubPubhas left
winfriedhas left
winfriedhas joined
thdoukhas joined
thdoukhas left
winfriedhas left
eevvoorhas left
eevvoorhas joined
nycohas left
Guushas left
Guushas joined
nycohas joined
winfriedhas joined
Martinhas left
eevvoorhas left
eevvoorhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
nycohas left
winfriedhas left
winfriedhas joined
Martinhas joined
winfriedhas left
winfriedhas joined
Guushas left
Guushas joined
eevvoorhas left
Kevhas joined
Kevhas left
adiaholichas joined
nycohas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
debaclehas left
winfriedhas left
debaclehas joined
thdoukhas joined
winfriedhas joined
debaclehas left
debaclehas joined
nycohas left
nycohas joined
nycohas left
thdoukhas left
nycohas joined
lsdlfjljuieI'm somewhat unhappy to see that people just post fotos of other summit participants on social media. I would have expected to be in an environment where people would at least ask beforehand...
adiaholichas left
adiaholichas joined
kusonekohas left
kusonekohas joined
kusonekohas left
kusonekohas joined
kinguhas left
dwdI can see arguments both ways on that. I would expect the summit itself to be public, and in the record.
winfriedhas left
winfriedhas joined
moparisthebestthe video stream was public
zashDon't you need permission to publish pictures from people in the picture?
moparisthebestdo we need an opinion from a lawyer in every jurisdiction again?
zashYes
zashAt least in the EU it should be somewhat unified.
zashAlso see the "Note Well" thing the IETF does.
Martin> Don't you need permission to publish pictures from people in the picture?
In germany you don't have the right on your picture anymore when you attend public events like concerts, summits and so on. I guess it's more or less the same in other European countries.
moparisthebestI don't think anyone would object if you attended the summit wearing a facemask, if you want your privacy
