emxpGuus, Ge0rG: Coming back to the 'new' Foundations discussion. My intention is a) focus on important issues in the xmpp comunity in general b) maybe put paid devs on these task or specific clients which are likey to improve the UX of xmpp in general (yes, money is an issue i know) c) build a platform/website to show what xmpp can do for standard users who never heard of xmpp before d) may provide general information about the network (number of users, how does xmpp work etc) - you get what my intention is? I dont talk about if that's likely to happen. I ask whether is the right way?
Guusemxp: I don't know. There likely is not one right way. If you see value in it, by all means.
(a) yes, 100%. I'm trying that for a while now.
(b) not only money is an issue, fair distribution of the money is as well.
(c) I'm not sure people are reading such websites, but it might attract some nerds / multipliers, so yeah! I wish we could host it on jabber.org...
(d) that's actually hard. The XSF is trying to, but you can hardly get reliable data from a federated system like XMPP
danielIf you are good at fund raising by all means go ahead. I don't think developers will say no to money
danielIronically fund raising is a full time job. So as soon as you start you'll have to raise enough money to at least pay your own salary
Ge0rGdaniel: actually, to pay for two people.
Ge0rG...so that you have one effective developer
danielMy personal approach is to create a sustainable business model. I know that's quite revolutionary idea in today's world. But you it might be more... sustainable...
zinidsustainable model is to get hired :D
mathieuidaniel, did you think about pitching your idea to a VC to get funding? :p
danielzinid, only if that company itself has a sustainable business model. i'm sure the matrix developer can agree
Ge0rGI've heard that Erlang an C++ developers are in high demand...
emxpdaniel, Ge0rG: For me there is no direct discussion of fairness. the foundation can act transparent, only invest in open source code and only spend money to task/work they all agree to. based on some principles - opensource, leading for xmpp, of intrest for xmpp community etc.. If people dont agree to those projects, they wont spend. so the foundation is forced to define task which are in the interest of most xmpp users somehow... or they can define task, the necessary effort, and let people donate and offer like 10-20% of the necessary amount. It's better to have a central plattform to collect task, than wait for third party aproaches maybe
emxpI think most people, dont like to donate, if they have no idea, about where the money goes
KevPushing only OSS projects sounds like a Really Bad Idea, given where so much of the XSF's expertise and effort has come from over the years.
mathieuiKev, yeah, although I can see the point if people are donating the funding
emxpmathieui: what do you mean exactly
emxpKev: Just an example. What software would you suggest to support?
ZashSome may find it weird to donate to commercial projects.
KevAh, this is a separate 'pay for software' foundation? I thought you meant the XSF.
KevIf it's some 'pay for opensource XMPP foundation', it's fine to focus on open source.
KevZash: Sure, so it has to be both non-commercial and open source? :)
Ge0rGKev: I think that OSS is the only way to ensure that the software won't just fold up and die at any moment in time after or before the funding stops.
KevGe0rG: I don't think OSS ensures that at all. But I understand what you mean.
Ge0rGKev: with closed source, there is no way at all to achieve that.
Ge0rGKev: and there are many viable business models around OSS, so I don't think this is about offending commercial closed-source providers.
KevAlso not true, but it's harder to get anyone to agree to it.
Ge0rGKev: it's always hard to agree on how to spend money. Your first remark is a good example of that.
KevGe0rG: If the business model is viable, we don't need a new foundation to be fundraising to inject money, I suppose? :)
Ge0rGKev: so we need to focus our money on non-viable business models. Wow, that sounds like a very awful framing of paying for non-commercial OSS development.
KevI don't have any problem with someone running a "raise money and we'll give it to projects" org, BTW. I misunderstood and thought it was suggested to do it through the XSF, which I disagree with.
KevI think the prospect is filled with difficulties, but as long as it's not the XSF that's shouldering them, more people working in XMPP is good :)
Ge0rGThe more I think about it, the more I like the idea of resurrecting the Jabber Software Foundation.
mathieuistart writign JEPs
Ge0rGWhich is my second "it used to be more appropriate in the past" epiphany after "message routing was better before Carbons, and we should try to get back to it"
mathieuistarts writing JEPs
KevRouting was better before carbons?
ZashGe0rG: I suddenly have this urge to tell you something along the lines of "I told you so"
Ge0rGKev: I've been pondering about how to improve the message routing mess we are currently in, and my proposal for a future XMPP would be this:
- messages to the bare JID are persistent, routed to all online resoures and archived
- messages to a full JID are ephemeral, only routed to the target full JID (or bounced) and not stored.
Ge0rG- resource locking must be burned with fire.
Ge0rGand this is very close to XMPP message routing rules pre-Carbons
KevI'm fine with that in principle, although we're not ready for "resource locking must be burned with fire." because of not having a sensible caps story yet, but we could get there. We need to anyway, because of carbons.
Ge0rGExcept there is no sane way to get from here to there.
Ge0rGKev: because of carbons and archives.
MattJThere are ways though
Ge0rGand race conditions.
KevThe idea of not doing full-JID fallback is sensible enough, in a MAM world.
KevBut only if you archive. Hmm.
Ge0rGKev: if we make full-JID synonymous with ephemeral, there is no need for fallback.
Ge0rGBut reassigning the semantics of full-JID is a tough call.
KevExcept for requiring a forklift upgrade.
Ge0rGKev: I'm open to less radical suggestions.
KevI was trying to think through whether it was possible for a 'modern' client on a 'modern' server to accept messages in 'old' style, but still do sensible things.
Ge0rGKev: but I think it's important that we analyze the situation we are in, determine that it's a huge mess, and have a vision of where we want to be in X years.
KevI guess there is.
KevIf we in some way mark sessions as being xmpp 1 or xmpp 2.
ZashDesign from the top instead of the bottom?
Ge0rGKev: https://wiki.xmpp.org/web/XMPP_2.0 ;)
KevGe0rG: I don't disagree with that. I've been trying to do this for some time.
Kev(that being working a way out of the mess)
Ge0rGand I'd love that vision to be "XMPP(-IM) is a transport protocol to synchronize a message history between a user's devices on login and live.
Ge0rGplus what we have with presence, that's working well more or less.
KevI think a long session at the next summit would be justified.
Ge0rGKev: +1 to that, though I don't know yet if I can attend.
KevOr a fully-virtual summit.
ZashGe0rG: Yeah, I too have this feeling that we've built a bunch of things that we don't know how they are supposed to fit togeather.
KevOr just a video chat between interested parties. Whatever.
KevI don't think IM/mail is the most productive way to work through such a core issue.
Kev(But I could be wrong)
Ge0rGKev: I think that whoever is going to attend a live meeting needs to understand the problem first.
ZashFOSDEM isn't too far away?
Ge0rGZash: it's not just a feeling, it's our current situation. Have a look at the interop between MAM and MUC, MUC and Carbons, etc.
Ge0rGEven presence in MUC is a challenge.
Ge0rGAnd the current situation is sufficiently f***ed up that we can't fix it by piling more protocols on top.
KevI think needing to understand the problem is why high-bandwidth is useful.
KevI'm not at all convinced that it can't be fixed by building on top, though.
Ge0rGI'm pondering about writing something long-ish to explain the problem as I see it and possible solution directions
ZashGe0rG: MAM, MUC, Carbons, SM, Push, CSI etc
KevAll your examples there included MUC.
ZashAnd the number of things involved has grown to be more numerous than what fits in my head
KevBinning MUC and replacing it might be an idea...
Ge0rGKev: what Zash said.
Ge0rGKev: how should Carbons and MAM interact with 0184 ACKs for example?
KevI think they're all necessary. Whether they're called individual things, or xmpp2core just gets really long.
KevYou need archiving, you need groupchat, you need routing rules, you need app-level acks, you need push, you need bandwidth management...
Ge0rGKev: all those things are needed, yes.
Ge0rGKev: that's not the question. The question is how to make them work together.
Ge0rGThey are all individual patches for individual problems, and they interop badly.
KevI'm far from saying everything's perfect. I challenge the notion that things can't be fixed without binning the core, though.
KevAnd we certainly need The Big Picture sorted.
Ge0rGKev: this is not about binning the core.
Ge0rGKev: but about some of the assumptions it made that are not appropriate any more.
KevYou'll remember (you won't, actually, because it was before your time :)) that I started a protoXEP for this many many years ago, but we didn't have the building blocks to solve it. It was in the days before MAM et al.
Ge0rGKev: I'm not intending to replace XMPP with JSON-REST. But I want to start from The Big Picture and see what needs to be changed to make XMPP2 work well.
KevI'm very much in favour of big-picture here.
emxpKev: Yes, i was talking about a different organsisation and if my thoughts are senseful
ZashAnd big-picture needs a big whiteboard! :)
KevMaybe Ge0rG should publish a Thought-A-Day on each of the problems he sees with the current state, so it's not TL;DR, and at the end of the series we've got the full picture :D
jonaswKev, I thnik he started a blog series :)
KevOdd, I thought I had planet jabber in my feed.
jonaswdoes the xmpp.org blog federate to that?
zinidI'm lost, xmpp2.0 is coming?
zinidjust don't use XML anymore :)
zinidor JSON if that matters
zinidJSON is XML of nowadays
zinidkids from 2030s will laught at us again
ZashWake me up when ASN.1 is cool again
zinidit's not modern, ya know
zinidprotocol buffers is THE THING
Ge0rGactually, protocol buffers is one of the saner protocol designs.
jonaswZash, ASN.1 over XML over JSON over HTTP over XMPP over VTEP
jonaswGe0rG, I’m not convinced by their implicit defaults.
Ge0rGKev: I've started a blog post series on "Easy XMPP", which is different. I think for this one, I'd rather go with my personal blog and the "xmpp" tag there.
Ge0rGjonasw: admittedly, I haven't had a deep dive into it. But any protocol that doesn't implicitly encode data lengths and uses escapable special markers is sane for me.
Zashjonasw: Considering ASN.1 being something of a schema thing, and the existence of an XML encoding of it ... I wonder if there's a JSON one yet.
Ge0rGhttps://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89 was an awesome post showing that all the modern web protocols actually fail the same way the US telephone network did in the 70ies. Mixing of meta-data and data.
ZashMake Gohper Great Again
Ge0rGThe author is calling it "buffer overflows" and meaning "lack of explicit buffer lengths", but it's all the same story.
ZashDon't LangSec people say that that's a giant security hole too?
Ge0rGZash: that what?
Ge0rGKev: I'm just not sure if I can start with individual problems and somehow arrive at the big picture.
ZashWhop's, bit got flipped in the length field and everything turned into a giant buffer overflow!
ZashSomething something length fields don't fit into some simpler language category?
zinidGe0rG: why not prefix length? you can parse it in parallel, unlike scanning
ZashLength prefixed fields helped so much there
Ge0rGZash: the issue with heartbleed was conflicting length fields.
zinidZash: using same logic I would say don't use C then
jonaswzinid, that’s a reasonable statement :-)
zinidwell, yes :)
Ge0rGZash: besides, my point wasn't that old protocols are sane, just that the current ones are mad.
zinidyeah, like http2
zinidtcp over http, wtf...
ZashGotta let Google have their optimizations
zinidright, today everyone is accepting what Google suggests, to be exact, what's good for their bussiness
zinidIETF is degrading
Ge0rGW3C has fallen.
Ge0rGzinid: https://jacquesmattheij.com/the-web-in-2050 is for you :P
zinidGe0rG: wait, I didn't finish reading your first article (about kill web)
zinidGe0rG: for the record, from your article:
> The fix: All buffers should be length prefixed from database, to frontend server, to user interface. There should never be a need to scan something for magic characters to determine where it ends. Note that this requires binary protocols, formats and UI logic throughout the entire stack.
ZashI forget where I read it, but you shouldn't underestimate human-readable protocols and formats. At least not for early versions. Later versions being binary might be sensible.
ZashIt was kinda cool way back in the day to open the XML console and see something that made sense.
ZashOr View Source and reading the HTML and stuff.
Zashcan't do that anymore tho, not with all the minifications and whatnot.
zinidZash: yes, it was cool because there were no encryption, I used tcpflow for this ;)
HolgerNot sure why $length:$readable_data would be impossible though.
zinidactually, there can be well-defined mechanism to dump structures in human-readable form
zinidlike they do for WebAssembly
ZashDo binary protocols usually have that tho?
ZashLike, included by default and accessible?
jonaswZash, protobuf does
zinidZash: I don't think so, but it's not that hard to write rules how to dump protobuffs structures for example
jonaswZash, $homebrewbinary probably doesn’t
zinidand dumping structures is trivial and not error prone (almost)
zinidunlike parsing them
ZashSure sure, but text formats make it really easy to get into fiddling with things, which helps with early adoption.
ZashOf course it comes back to bite you later, but still.
zinidthis is the same argument as Python vs Haskell
zinidPython will bite you later for sure
zinidduck typing accepts no excuses
ZashDuckt tapeing ftw
Ge0rGHolger: it's not impossible with human-readable formats, but then you end up with whitespace or newline in the wrong place and the parser freaks out :(
jonaswGe0rG, #poezio? ;-)
zinidanyway, I'm relaxed, because I implemented XML codec for ejabberd, it does the same as asn.1/protobufs/etc and it works (despite everyone cries you should not validate)
Ge0rGjonasw: no way :P
jonaswGe0rG, a good example of a working system is the chunked HTTP encoding
Ge0rGjonasw: how many HTTP entities will accept unix LF instead of CRLF, what do you think?
jonaswGe0rG, right, it’s CRLF
ZashThe finer points HTTP header syntax will make you mad
jonaswZash, I’ve seen a fun talk about that
jonaswforgot how it was called
Ge0rGjonasw: also is there a CRLF at the end? https://stackoverflow.com/questions/33878377/why-are-some-servers-not-using-crlf-after-the-last-chunk-length-of-zero ;)
jonaswbut they made ascii-art out of well-formed HTTP headers, soo....
jonaswTIL there are trailers
Ge0rGmovie trailes? or the ones you live in?
jonaswGe0rG, the ones behind the last chunk in chunked transfer encoding
jonaswread the answer you linked :)
Ge0rGOh. My. God.
SamWhited> tcp over http
I start twitching every time I hear that because it makes me think of BOSH…
zinidbosh... plz god no
Zashspeaking of which, anyone feel like going around the interwebz and purging old pre-standard xmpp-over-websockets implementations?
MattJSorry, I have a soft spot for BOSH
zinidI have a bunch of issues related to mod_bosh, it's brutally hard to debug with all that overcomplicated sid/rid/cid crap
zinidjust terrible protocol
SamWhitedIndeed… impossible to debug, hard to implement in any reasonable way, can't really be decoupled from the underlying thing it's transporting (although the XMPP over websocket protocol is that way too)
SamWhitedit's a right pain.
Ge0rGThere is a followup to kill-the-web: https://blog.plan99.net/what-should-follow-the-web-8dcbbeaccd93
fippohave you heard of dns over http aka DOH?
Zashfippo: It needs moar JSON
zinidCan't we deprecate bosh btw? Do we still need it when we have websockets?
pep.https://caniuse.com/websockets I suppose we could
Ge0rGzinid: are you going to pay the developers of all BOSH clients to migrate?
Ge0rGAlso I wonder how that will work with TCP interruptions, bad firewalls / web firewalls, etc.
Ge0rGAlso how good is WebSocket library support for non-webbrowser applications?
ZashMaybe we should have standardized two xmpp-over-websocket versions. One with WebJS fiddlery and one that's just the same as TCP but over WS
ZashDoes Websockets work with all those restrictive corporate firewalls that are forcing everything into becoming https on 443?
Ge0rGZash: I think WS is masquerading as HTTPS, but of course with irregular traffic patterns.
Ge0rGZash: so it will work with the subset of firewalls that don't look too deeply into the traffic and don't have low timeouts
moparisthebestzinid, excellent work on TLS SRV patch :)
zinid> are you going to pay the developers of all BOSH clients to migrate?
Wow, we now care about backward compatibility? What about private storage, vcard avatars, privacy lists? Who payed the developers?
mathieuizinid, nobody, and most clients are still using private storage
zinidregarding firewalls: it's just https traffice, timeouts will be handled by stream management
zinidmathieui: I know ;)
dwdzinid, I think we still need BOSH. We have to use it on occasion.
moparisthebestI'm biased, but I think web clients use websockets, and non-web clients use direct TLS, both are equivalent when over 443 as far as evil firewalls go
zinidmoparisthebest: I think this webby stuff is mostly for browsers now, no?
zinidnot sure why would a non-web client use bosh/ws
moparisthebestiirc gajim has a bosh implementation
moparisthebestbut I agree it *should* be
ziniddwd: can't we use ws occasionally? :)
dwdWe experience browsers with websockets explicitly disabled. This is far from ideal, but still, they exist.
moparisthebestdwd, I didn't know that was a possibility
mathieuizinid, when you have no other choice for direct connection, ws/bosh in desktop clients seem like a nice fit
KevWe experience browsers too old to websocket, too.
Kev(Yes, yes, I know, I know, but they do)
mathieuihopefully they will be 0dayed into history before long
ziniddamn, so I need to fix those mod_bosh bugs :(
dwdzinid, Also, I don't think your IPv6 is working.
ziniddwd: it doesn't, yeah
zinidsomething wrong with firewall probably
dwdKev, No, we're seeing new browsers, but with it disabled. And no, I didn't know either.
moparisthebestmathieui, but for a desktop client direct TLS is also a (far easier) option whenever ws/bosh is
Kevdwd: Yes, you said that, I didn't doubt it.
mathieuimoparisthebest, sometimes you cannot
ziniddwd: the problem with ipv6 is I have nowhere to test it from
ziniddwd: I don't have ipv6 at home, so...
moparisthebestmathieui, aren't you connecting to ws/bosh over direct TLS ?
moparisthebestunless you mean, fully in-the-clear-no-tls-xmpp :/
pep.moparisthebest, sometimes non-standards ports are blocked
mathieuino, I mean, you can proxy those from 443 with nginx
moparisthebestand you can alpn (or protocol-inspect, ew) xmpp and http to xmpp server or nginx on 443
moparisthebestit all depends on the server to have it set up properly, but bosh/ws does too
jonaswmoparisthebest, alpn will be blocked by firewalls if they really want to
moparisthebestyes it can be, and probably will one day, but not by wifi hotspots in coffee shops most likely
moparisthebestalso why it's not required, daniel and I talked about it back in the day, conversations will probably try with alpn and if it fails then without it, or vice versa
moparisthebestso today, using alpn, you can have client -> sslh (based on alpn) -> (prosody,nginx)
zinidyeah, ALPN is a really bad idea if you want to bypass the DPI: you're literally saying: "hey, I'm jabber"
moparisthebesttoday you could also, without alpn, have client -> stunnel (or something decrypting TLS) -> sslh (based on xmpp/http) -> (prosody,nginx)
moparisthebestthe original spec sent the SRV name in SNI and used that to multi-plex :P
moparisthebestno one liked my wanton abuse of SNI though :'(
dwdmoparisthebest, Wouldn't work in Java, I think.
zinidfor the record, I heard it TLS v1.3 sni and other extensions will not be that easy to inspect
zinidcan somebody confirm?
zinidI tried to read the I-D, but it's brutal
moparisthebestyea TLS lib support for "serve the certificate for xmpp.org when server1.xmpp.org is in SNI" is probably spotty/non-existant
moparisthebestI used sslh to multiplex on SNI and prosody just served the 1 cert regardless meh
moparisthebestzinid, I know people were pushing to encrypt SNI/ALPN but last I heard it was abandoned to the future, they might have done something to obfuscate it or something, not sure
zinidmoparisthebest: too bad, because the government firewall is annoying (it detects SNI)
moparisthebestah that sucks
dwdzinid, We could work around that.
dwdzinid, Use starttls to establish the session and then resume it on directtls.
moparisthebestyou are just announcing it another way, also they could inspect the certificate coming back couldn't they?
ziniddwd: but starttls can be detected easily
moparisthebestso my work on 443 just holds your connection up temporarily, connects on it's own to see if the TLS handshake succeeds (and only supports TLS 1.0), and only if successful lets your connection through
moparisthebestso if you only support TLS 1.1+ it won't allow that either, without also supporting 1.0...
zinidyes, they could inspect the certificate
zinidso I would prefere all parameters to be encrypted
moparisthebestit's a shame to have to consider that at a country level
moparisthebestbut nowadays even 'free-er' countries like UK look like they are moving in that direction...
zinidright, you never know who's next
zinidso this should be developed now
zinidthus I'm wondered the TLS folks abandoned the idea
moparisthebestit's been a year or two since I looked, hopefully it was picked back up idk
moparisthebestthe reason was because it breaks all the multi-plexing TLS business like I do with sslh
moparisthebestso akamai and such were super against it
moparisthebestsafe to say it's actively being worked on
zinidbut 20 pages...
ZashWeren't all the CDNs strongly opposed to that?
moparisthebestha yea it's not short
Zashoh you said that
Zash20 pages is not what?
moparisthebestbut whatever they come up with there in theory should apply equally to ALPN
moparisthebestZash, he is saying https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 is 20 pages long
zinidmoparisthebest: there is a lot non-normative text, it's fine after all
moparisthebestI can't find anything about ALPN encryption
SamWhitedI hadn't seen that; might be interesting to try and do an early implementation in our TLS 1.3 stack. I might give that a shot one of these days if I can convince my boss to loan me to the crypto team for a bit.
SamWhitedDoes it look relatively implementable in its current form?
Alexralphm: yes, but we also said we should stick the 12 month term
ralphmYeah, I know
ralphmSo this is a good time to start then, right?
Alexwe had discussion a while ago to either make a term longer or shorter once, and agree on a fix schedule
AlexI think Peter proposed a calendar year, Jan 1st to Dec 31,
Alexralphm: yes, this is why I have it on my TODO list for this week
AlexI can setup the Wiki page this evening, and send out an Email
Alexis on EST time this week
moparisthebestcalendar year makes sense for serving times, you'd still want the vote (much?) earlier though to avoid voting over holidays/new year
SamWhitedIt seems like if you did calendar year that the first meeting would never happen because people would be on vacation.
moparisthebestthat TLS SNI encryption RFC is making my brain hurt
ZashRFC? Wasn't it an I-D?
zinidmoparisthebest: it's http fronting, not sure how it's better than tor for example
zinidI read it too
SamWhitedI should figure out how the printer in this building works so that I can read it…
zinideasy in fact
zinidThe current draft proposes two designs for SNI Encryption in TLS.
Both designs hide a "Hidden Service" behind a "Fronting Service". To
an external observer, the TLS connections will appear to be directed
towards the Fronting Service. The cleartext SNI parameter will
document the Fronting Service. A second SNI parameter will be
transmitted in an encrypted form to the Fronting Service, and will
allow that service to redirect the connection towards the Hidden
ZashSamWhited: PC LOAD LETTER
ZashI should figure out how to turn arbitrary RFCs and I-Ds into epubs or something I can read on the eink thing
ZashIt's a pain, but at least I don't have to deal with printers.
zinidwhat is a problem to ban this "fronting" sni?
zinidI really don't get it
ZashWait so it's TLS over TLS???
zinidZash: yes :)
jonaswrfc-std.epub appears to contain all the RFCs. It doesn’t take at all long to load on my machine....
ZashI believe I have one of those already
ZashNot the most optimal to navigate unfortunately
zinidah, I got it, you can use any junk in the Fronting SNI
moparisthebestpep., Council meeting minutes 2017-08-30:
Vote on obsoleting XEP-0146 (Remote controlling clients)
Period has expired with missing votes from Tobias and Dave.
Dave and Tobias say they are happy with their implicit +1s.
moparisthebestso, officially, it's deprecated, I think? editors? :)
jonaswI remotely recalled there was something like that, thanks for pointing this out
jonaswmoparisthebest, I can’t find it in the council minutes you mentioned, are you sure it’s the correct date?
jonaswyeah, that indeed needs Deprecation
moparisthebestjonasw, btw if you want to add alpn support to your client I can give you a test account on my server
Zashjonasw: btw a big reason why I wanted xep->markdown was to produce epubs using pandoc, and it works pretty well for that
pep.https://xmpp.org/extensions/xep-0267.html what about "Server Buddies"? Anybody using it?
ZashI wanna use it for all sorts of things, but haven't gotten around to it :(
moparisthebestpep., this references it https://blog.process-one.net/wp-content/uploads/2016/07/Fighting-XMPP-messaging-spam-thanks-to-ejabberd-API.pdf
moparisthebestmore in a 'for the future' way
GuusI've applied the logo change in most of the obvious places
Guusif someone finds an old logo somewhere, please let me know