pep.Can participants fetch MUC-registered nicknames of other participants?
DanielWill those appear in the member list?
DanielThat's probably way underspecified. But it would make sense
DanielSince prosody is the only implementation that even has registration ask MattJ?
Ge0rGMattJ proposed to send all registered participants that are not an occupant with unavailable presence.
pep.(one more place to fetch nicks yay)
Ge0rGIMHO, sending a bunch of unavailable presence with a join shouldn't break anything
DanielBut yes that probably makes sense
MattJpep., "one more place" -> the idea was to consolidate them all into this one place (presence), so the client only has one mechanism to track occupants
MattJIn my head I have a draft thing for MUC join flags to opt into things like this
MattJand also to filter messages, e.g. bots that only want to receive certain things or from certain occupants (and enforcing this server-side if necessary, so it becomes safe to add bots to a room without them logging your conversations)
DanielUh. Like muc/sub
Ge0rGMattJ: also a flag to not send occupant presence and a roser-versioning-alike thing for the participants?
pep.MattJ: there are other places where a client can fetch nicks / display name that a MUC doesn't have access to
MattJpep., oh, sure
MattJDaniel, quite possibly, but I'd actually put this through as a XEP and hope to keep the changes simple enough that it gets adoped (if other server devs even care about improving MUC anymore, it's possible that they don't)
MattJDaniel, quite possibly, but I'd actually put this through as a XEP and hope to keep the changes simple enough that it gets adopted (if other server devs even care about improving MUC anymore, it's possible that they don't)
Ge0rGI still think that improving MUC is worthwhile. MIX has become a significant engineering effort.
DanielImplementing it on the client side is probably easy
Danielbut for me the biggest issue with MUC is reconnection/reliability
Danielbefore we can solve that it feels a little pointless to waste time and energy on other improvements
Danielbut I understand that different people have different priorities
Danieland/or that work on one improvement doesn't block improvements on other fronts
Ge0rGDaniel: did you make any progress on the per-MUC push registration?
Danieli even removed the code again
Danielbecause it was causing some weird edge case bugs
Danielwhere the server was maybe at fault
Danieland nobody had implemented it
Ge0rG"weird edge case bugs" is the long form of "MUC"
Danielwell i think it wasn’t even muc related. but a server announced push and muc on the primary domain and then it registered itself 100 times or something
pep.What happened of 410 on s2s?
DanielI don’t recall the details. but i didn’t feel like fixing it or finding work arounds for it when it was dead code anyway
pep.MattJ, any hint about my first questio nbtw
pep.MattJ, any hint about my first question btw
Danielnot on s2s but having your server do it?
Danielbecause 410 on s2s would just be regular ping, no?
pep.yeah, servers doing "410"
pep.Whatever it takes to keep the link on. Which is also gonna be a problem for MIX anyway
Danieldidn’t eta want to come up with a thing
Ge0rGMIX has the additional problem that there is no plan for recovering from s2s outages.
Ge0rGMUC is self-healing, more or less, once you rejoin
Danieli've heard matrix has something for that
Ge0rGMIX... good luck.
Danielwell your joins/leaves are IQ based so you know if that was succesful
Ge0rGWe also have the same problem with MAM.
Danieland then you might just lose messages
Ge0rGBecause apparently, combining "give me everything I missed" and "enable live delivery" is a HARD problem
MattJpep., from example 131 in XEP-0045 it looks like the affiliation list includes the nick, so yeah
pep.Ah, thanks. I missed it indeed
DanielMattJ, does prosody already include that?
MattJJust found the test: https://hg.prosody.im/trunk/file/tip/spec/scansion/muc_register.scs#l397
etaDaniel: yeah I have half a protoxep about automatically reconnecting to MUCs that I never finished
pasisHi, I've refreshed library in libraries.json, but xmpp.org hasn't been synced. Could someone update xmpp.org? The library is libstrophe.
Sevepasis: It was merged though, right? I think I did
pasisyes, it's merged, just doesn't appear at xmpp.org
pep.Yeah docker things probably need a push
jonas’they need a pull :-X
jonas’joking aside, will do
vanitasvitaebtw. there are some stale PRs on xsf/xeps that are ready for processing by the editors, namely https://github.com/xsf/xeps/pull/923 and https://github.com/xsf/xeps/pull/932
vanitasvitaepokes editors with a stick
jonas’vanitasvitae, ah, I missed your approval on those, as I was on vacation during that time
jonas’will tag them so that I process them later tonight
jonas’thanks for the ping
vanitasvitaethanks for being an editor ❤️
pep.and I didn't really help :x
pasisit works now, thanks :)
dwd(Reading up) eta, I keep meaning to explore your ideas around group chats in more detail. I think I've read half your series on your blog, but keep meaning to read the rest.
etadwd, I mean it does peter out near the end; the only useful thing in that series is the whole "sponsoring server" model
eta(which you could implement with XEP-0045 today and a custom MUC component, and I indeed might one day)
dwdeta, Ah, yes - you had a hybrid model between XMPP's single authority and IRC's model of every server has to be trusted?
etadwd, exactly -- you have a quorum of trusted servers that use some consensus algorithm (Raft / Paxos)
etawhich is less crazy than Matrix's "fully decentralized" model (which I don't see being viable
etawhich is less crazy than Matrix's "fully decentralized" model (which I don't see being viable)
dwdeta, There's some work around on partially trusted consensus algorithms, too. Kind of like BFT algorithms but each server might have different legitimate aims.
dwdeta, You definitely don't want Paxos, though. And even Raft has some problems if we assume byzantine fault tolerance and dynamic group membership is desirable, I think.
etadwd, very potentially! I never really went anywhere with this; it was just an idea
etawhat could be interesting is just to piggyback of something like etcd, which already handles the distributed state
dwdeta, Well, you could start with a simple Raft implementation, for exploratory purposes.
Shelletcd is just a Raft implementation on top of a k/v store, isn't it?
dwdeta, And I think you don't need to worry too much about formal consensus for most things, you can do elections and a tree-based fanout for messaging, for example.
etadwd, yeah, I mean you only need consensus for things like the room member list
KevAm I misremembering Raft, or isn't it a leadership-election thing? So fails if you need to continue functioning in a split situation?
dwdeta, ... maybe? I'm not sure that needs consensus until the point where a member is more than a mere passive observer.
etadwd, no, sure
etaI meant more bans/voiced users/etc
dwdKev, It might have leadership, but it survives partition. It is not, however, eventually-consistent, so an orphaned member ceases to be available.
KevThat is, I believe, what I intended to express. The majority split functions, the minority split doesn't.
etaKev, the thing is you can just queue messages in the minority split until it rejoins
Kev(Sorry, dev version of client)
dwdKev, But eventual consistency and message ordering are, I think, problematic, unless your UX makes things very clear. FMUC solves this, I think, by making that UX affordance possible.
Keveta: By 'messages' here do you mean <message/> or the log entries from Raft? If it's <message/> then there's lots of other modifications that could happen during a split that are hard to deal with, I think.
pep.I don't know Raft nor Paxos. Why would a minority not continue working on its own? redo elections etc.?
pep.Resources I can read?
Shellbecause the minority can't know that what it does is compatible with the state of the majority.
Kevdwd: Yes. It's not even the message ordering that most worries me though, it's the other state changes, e.g. banning a user and making them an owner on different nodes (the old IRC netsplit op attacks are an extreme symptom of this).
dwdpep., Have a look at "CAP Theorum", as a good general start point.
Kevpep: In order to win an election you need to have a majority vote. If you're in a minority split you can never have a majority vote. The leader is the Source Of Truth for the replication, with it being responsible for ordering the log messages. So if you had two leaders each claiming to be the Source Of Truth, bad things happen. At least from memory, I've not looked at Raft properly in a few years.
dwdKev, Broadly, this is true for almost every consensus algorithm that eschews eventual consistency.
pep.Kev, right, your use of minority / majority "only" makes sense when you try to merge back :p
pep.Thanks for the pointers
etaKev, I don't see how you can do split riding though
dwdKev, But also, I don't think the netsplit op attacks are possible if you don't have an eventual-consistency style.
etaif you're in the minority partition, disallow all state changes
dwdeta, Not just state. Message reordering can lead to some interesting problems.
KevRight. That (eta) obviously avoids the complications, at the cost of degraded service. But note that 'state' here includes message publishing.
dwdAnd when I say "interesting", I mean in the sense of people dying.
Ge0rGJust DAG everything?
etaremembers dwd makes healthcare messaging software
dwdeta, Not that context actually, but yes.
etawait, so explain how message reordering is problematic?
dwd"Is the patient breathing?" "Yes" "Have you checked for spinal injury?" "No". Rearrange for much fun.
etaright, but you can't flip the yes and the no here
etaassuming the asker and the responder have a netsplit between them
etabecause the behaviour in event of partition is to queue
Zasheta: is your blog on planet ?
dwdNo, but if the "Yes" follows "spinal injury" people get pretty confused very quickly.
etaZash, don't think so
Ge0rGeta: you can get nice reordering effects if there is a third party reading, and they have intermittent s2s issues
KevMy (not exhaustive, but I've spent more time on this than one might like) experience of things-that-can-go-wrong in situations like this is that whenever I think "But at least X can't happen", something else that's equivalent to X ends up being able to happen.
dwdGe0rG, As for DAG, that does deserve a special place in hell. People don't talk in DAGs, they talk linearly. The way to get DAGgy in conversations is to thread them and present a UX that then makes sense, and somehow encourage users to use that threading sanely.
Kevdwd: Our conversation here is a DAG. It's just a very specialised case :)
dwdKev, Yes, yes. Have a sticker. :-)
Ge0rGKev: is it really? Each message is either a root or a reference to some earlier message.
etaif you *really* cared about message ordering you could replicate messages in the raft log
dwdGe0rG, A linear graph is a proper subset of a DAG, I think he means.
etabut that would add quite a deal of latency
Kevdwd: Honestly, a decent sticker would brighten up my day Quite A Lot right now.
pep.Some people want want ./·_./·_./·_. :x
Ge0rGdwd: yes, that's what I conlcuded from the message as well. My point is that this conversation is not a linear graph.
pep.Some people want ./·_./·_./·_. :x
pep.And not a full dag
Ge0rGpep.: is that morse code?
dwdGe0rG, Morse did drink a lot.
KevGe0rG: I'm as surprised as the next person that my joke doesn't stand up to scrutiny.
dwdKev, It's been rejected at peer review stage, but is still available as a pre=print, so I guess you win?
KevAcademic journal peer review is a process I will be very happy not to go through again (on either side).
Ge0rGI suppose normal people are not deep into partially ordered histories, right?
KevGeorg - if you mean that it's only the 'mission critical' (for want of a better term) situations where ordering matters, I think 'normal' people care about it too, it's just less bad when it goes wrong.
pep.Ge0rG, it's supposed to represent a special shape of tree :p Dunno if that has a name
Ge0rGKev: what I intend to say is this: if message history is implemented as an eventually consistent DAG, people won't be able to grasp the concept and draw the right conclusions regarding message ordering. Not in normal times and especially not during a crisis
KevAh. Yes, I think a UI needs to de-DAG it in order for it to be reasonably understandable.
dwdeta, Anyway, if you always send messages to the top of a conceptual routing tree, so a single leader elected for the purpose, but handle state changes through a consensus algorithm, then I think we're good. If you use a Byzantine fault tolerant algorithm, and use it sparingly, then I think you more or less get reasonable performance with highly resilient state - as long as you're not connected to a node which loses connectivity with the others in the consensus group.
pep.(Basically meant to say some people want to be able to reply to a single message)
dwdKev, Or as pep. suggests (I think), Slack-style "threading".
Ge0rGAre we talking about threading or about message history consistency?
KevI note that me saying that things like Raft don't solve all aspects of CAP (yes), doesn't mean that using Raft for MUCs (which are currently entirely SPoF) would be bad.
dwdpep., FWIW, I wanted to do Slack-style threading by spawning off a new chatroom as a child of the containing conversation.
pep.dwd, I hear that's how rocketchat worksss-ish?
pep.I've never used it
dwdKev, Also the whole point of CAP is that you can't solve all aspects of it.
KevI wanted to do Slack-style threading by spawning off a new message node within the channel.
Kevdwd: Yes, thus the "(yes)" to denote that I realised.
dwdpep., I... don't know. I do know some people who do a lot with Rocketchat though.
dwdKev, Ah, I thought so, but then I worried about people misunderstanding, but then after writing my last I realised that anyone familiar with "CAP" would know anyway.
dwdSometimes I should just not write things. :-)
dwdeta, Oh, and before I forget to mention it, the bit of your design I thought was interesting - and have now largely forgotten - was your approach to permissions at the group chat level, which seemed well thought through.
KevYou are probably right that I'm not expressing things in an observer-considerate way.
KevI've been thinking about ways to improve clustering within M-Link (and other things) recently, which is a very similar area, but with different requirements.
dwdYes - no need to conider Byzantine fault tolerance, but you probably so want to go the eventual consistency route for most things.
KevI hadn't realised it, but reading eta's article I'm starting to think I'm in the middle of re-inventing Matrix.
dwdKev, Thinking about the IRC netsplit attacks, were those entirely predicated on the combination of channels disappearing when nobody was in them (and thus being able to be recreated with different ownership) and a poor merge algorithm?
etathe fix was "improve the merge algorithm"
etaso the channel with the earliest creation timestamp wins
KevWell, that was one of the fixes. I've also seen (maybe not recently) disallowing channel creation during a split.
ZashOh glob not merge algorithms
KevYou can't *not* have merge algorithms of some sort, if you want eventual consistency.
KevYou may as well say "Oh glob, not eventual consistency", which would probably be quite fair, it's a lot more of a brainfuck to reason about than something like Raft.
etadecides people should just use single servers and avoid making a distributed system where possible
dwdeta, We already have a distributed system in XMPP; we just have a fixed leader and all decisions are made by the leader. That's a valid solution to be problem; it's just that if you want to address the shortcomings (like the leader being a SPOF) then things get complicated.
dwdeta, Most notably, because our distributed system is a heterogeneous distributed system already.
etaah, that is porn
edhelasyes, but uploaded using HTTP Upload !
etayeah, which meant I clicked on it
etaand now it's on my screen and I can't delete it
pep.quick quick send new messages
ZashMessage Moderation to the rescue?
dwdScrolling, scrolling, scrolling.
vanitasvitaeluckily I waited before clicking
dwdGet them wagons rolling.
edhelasgot a nice preview on Movim :D
vanitasvitaebut yeah, deleting images in dino would be nice
pep.Zash, I think allowing a user to stop displaying a picture would be nice nonetheless :/
etamakes more noise
Ge0rGSome clients will just auto load images
edhelasactually it's the best way to wake up a channel it seems 🤔
etayay, it's off the screen now
pep.Good, now we can go back to sleep
ZashPretty sure I enabled moderation here, so you can go in and delete it from the archives even
edhelaspfieuw, now let's go back to normal
dwdAt least we're considered a worthwhile audience for porn spam.
Ge0rGYou can't solve social problems with technical means. If you block images, they'll send ASCII porn. Or illegal text content.
etaZash, but isn't it just converse that does that
edhelasonly XEP pr0n is allowed here, I like reading 0060 for example
etathat's the good stuff
vanitasvitaeguys, follow my OnlyXEPs account!
Ge0rGedhelas: you pervert!
edhelasyeah, I love those Romeo & Juliet stories
pep.While there is some activity in here: in 20 minutes we have a SCAM meeting in xmpp:email@example.com?join and we're talking about Summit. Please join if you want to follow and/or have ideas on the organisation side of things
vanitasvitaepep., thanks for the heads up
JustLikeThatI have a proposal 🙂
mdoschPorn again? This time moving pictures?
GuusBetter moderating support in clients is going to become more desirable.
GuusEG: make a room temporarily moderated, hand out voice, stuff like that.
CognitiveDissonanceI was wondering, what is the *fundamental* difference between XMPP and Matrix?
MattJGreat question :)
DanielFundamental from an end user experience probably not
MattJI think the fundamental difference is that XMPP is based on routing stuff, and Matrix is based on distributing stuff
etaCognitiveDissonance, Matrix is fundamentally a database (a graph data structure that's replicated across servers; the spec defines how to replicate the structure), whereas XMPP is based on passing messages around (the spec defines how messages should be routed to different clients and optionally stored)
CognitiveDissonanceAh, routing vs distributing seems like a core difference.
CognitiveDissonanceAlso, is matrix completely web-based?
etathis is why Matrix servers need more resources to run; because they spend a lot of energy doing this replication algorithm
DanielDefine web based.
etawhereas XMPP messages are simple and easy to route
DanielYes it uses http.
Kev> easy to route
CognitiveDissonanceDaniel What about xmpp?
moparisthebestbut if "http" is your criteria then XMPP is also web-based
Danielc2s *can* be http
moparisthebestbecause it can be used over http
Daniels2s is tcp
Danielor at least we haven’t speced out a way to use s2s over http
Danieli guess we could
CognitiveDissonanceSo in terms of design principles like modularity, simplicity and extensibility, what is the diff b/w them?
CognitiveDissonanceDaniel Hmm, I always seen only xmpp://foo and not http://foo, for c2s
Danieljonas’, well I was just answering a question.
moparisthebestXMPP has proven to be very extensible based on continuing to work well 20+ years after it started, matrix on the other hand... they are asking users to migrate servers because they can't scale
Danielbut you might want to run servers behind more restrictives firewalls
Danielon your raspi or something
MattJRunning servers in the browser has been discussed in certain server projects before
CognitiveDissonanceDaniel: I see.
CognitiveDissonance* good point
etaCognitiveDissonance, so natively XMPP uses a TCP socket, but the BOSH (bidirectional streams over synchronous HTTP) extension lets you use it over HTTP
CognitiveDissonanceSp matrix is a monolithic system right?
eta(almost all popular servers expose that as an option for web clients)
moparisthebesteta, CognitiveDissonance also websockets
etayep, that too
moparisthebestI expect *very soon (tm)* xmpp c2s and s2s to start working over QUIC as well
CognitiveDissonanceeta Daniel Ah BOSH makes sense. Btw, xmpp server doesn't *require* web server right? matrix seems to rely on web server.
etaCognitiveDissonance, not at all!
etayou might want one for HTTP file uploading (XEP-0363), but it isn't a hard requirement
CognitiveDissonanceAlso, in DNS records, I notices xmpp has only SRV records, where matrix has only A records.
etathat's because matrix uses /.well-known
jonas’CognitiveDissonance, you need A/AAAA records for SRV to make sense
moparisthebestXMPP also has TXT records for some connection methods...
CognitiveDissonanceboon or a bane?
ZashMatrix uses SRV too
moparisthebestagain I expect *very soon (tm)* XMPP to start using http-svc/srv2 records or whatever the latest name for those are
Zashmoparisthebest: don't you dare!
moparisthebestZash, required for sni+alpn encryption!
moparisthebest(plus other things etc)
ZashDo not want
CognitiveDissonancei am scared of http and web tech stuff.
moparisthebestthat's the best thing about XMPP, even if you don't want it I can still have it and vice versa :D
CognitiveDissonanceToo many security issues
moparisthebestCognitiveDissonance, to be fair that's just "computers"
dwdCognitiveDissonance, To be cleat, Matrix need not suffer from those since it's not like it runs in the browser.
dwdCognitiveDissonance, To be clear, Matrix need not suffer from those since it's not like it runs in the browser.
dwdCognitiveDissonance, It just uses HTTP and JSON as its substrate layer, like XMPP uses XML. And XML has its own set of amusing security issues.
CognitiveDissonancedwd hmm, AFAIK, even riot/element desktop client is a web stuff via electron.
dwdCognitiveDissonance, Sure, the implementation of the clients is all web tech. But in principle it need not be.
CognitiveDissonancedwd. I see. I have seem in wikipedia that xmpp is a text-based protocol like IRC. what does mean?
dwdCognitiveDissonance, There are, I think, Electron-ish clients in the XMPP world. Certainly browser based ones.
jonas’CognitiveDissonance, it means that some bytes are not allowed in the streams
jonas’doesn’t matter in practice
dwdCognitiveDissonance, XMPP operates by exchanging XML fragments over TCP, not text. Matrix operates by exchanging bits of JSON over HTTP.
moparisthebestIRC operates by exchanging bytes over TCP, better hope you guess the encoding correctly!
dwd(Favourite thing about IRC is that the case-folding for usernames is based on whatever keyboard layout the developer happened to be using).
CognitiveDissonanceI was confused about "text-based". XML is not a plain text?
jonas’(dwd, wasn’t it the swedish 8-bit latin encoding thing?)
jonas’CognitiveDissonance, it is as much plain text as JSON is
jonas’Zash, ah, right
dwdCognitiveDissonance, It's generally textual in nature, but it's not plain text as such.
jonas’(I mixed that up with mysql, that was swedish)
moparisthebestif anything XMPP/XML and Matrix/JSON are much more "text-based" than IRC because the encoding is actually defined
CognitiveDissonancedwd: Ah, I am getting the fundamental difference now.
CognitiveDissonanceMatrix exchanges JSON over http and XMPP exchanges XML over tcp.
jonas’(over http over tcp/whatever atrocity google thinks of)
CognitiveDissonanceIf I put a VS (versus) in between ....
moparisthebestmainly yes, but more generically XMPP exchanges XML over (a stream)
dwdCognitiveDissonance, Well, possibly not. XML+TCP and JSON+HTTP aren't that different, really. The biggest gain XMPP gets from XML is actually the namespacing rules, which give us clear extensibility - but in principle you can transcode between the two with some rules. The much bigger difference between XMPP and Matrix is the fundamental model.
moparisthebestit's mostly TCP but it can be Websocket or a BOSH session today
moparisthebestQUIC or whatever else tommorow
dwdmoparisthebest, In fairness, plain TCP is rare since we're always using TLS.
moparisthebestright I didn't mean *plain* TCP but good clarification
CognitiveDissonancehttp is stateless and tct is stateful?
dwdCognitiveDissonance, Broadly meaningless. Matrix has state in its sessions.
dwdCognitiveDissonance, I mean, IP is stateless and yet XMPP has state. TCP has state too. XMPP sessions can span multiple TCP sessions. So whether TCP happens to have state isn't important - and HTTP runs over TCP anyway.
raghavgururajanconsiders xmpp like emacs. extend and extend and extend
moparisthebest"HTTP runs over TCP anyway" eh not so much anymore, http up to 2 does, http 3 does not
moparisthebestin a similar way that future XMPP won't have to :)
CognitiveDissonancehttp is application layer right? it requires tcp?
moparisthebesthttp3 runs over QUIC which is like TLS but over UDP
dwdMatthew Hodgson, of Matrix, once compared Matrix and XMPP as Mac vs Linux. I think perhaps iPhone versus Linux might be more apropos. Matrix gives you a bunch of stuff, and you get what you're given - though you can add more. XMPP gives you a low-level kernel, but almost everyone then gives you a distribution with a bunch of common software on top.
CognitiveDissonanceThank you all folks!!!
CognitiveDissonanceI appreciate it.
moparisthebestjonas’, DTLS is quite different than QUIC
jonas’moparisthebest, I don’t care
dwdI mean, finding a client or server that does XMPP and nothing else is *hard*.
moparisthebestit's akin to UDP vs TCP, you can't just drop-in replace one with the other, different use cases
KevYou mean RFC 6120 only? Impossible, I suspect.
dwdKev, I was thinking 6120+6121, which is in principle possible.
raghavgururajandwd: That is actually. Start minimal and extend. Keeps things simple and modular.
KevSorry, I didn't mean it was technically impossible to do 6120 only (although I think it probably is, because you'd need to replace 6121 with something else for the routing rules), just that I would be amazed if there exists any such software. Although I'd be moderately surprised to find something doing 612 and nothing else, but not shocked.
moparisthebesttry finding a browser that just does http
dwdmoparisthebest, Ooooh, I'm going to use that next time someone does the "Too many XEPS!!!111" argument with me.
ZashHTTP has too many RFCs!
raghavgururajanTo rewrite my message: What XMPP does is good. It starts minimal and then extends. It keep things simple and modular. Don't you all agree?
dwdBroadly, yes - I don't know how else we could have built it but start with a common base and add bits.
CognitiveDissonanceraghavgururajan I was looking for that difference in xmpp and matrix.
dwdMatrix can avoid this by essentially being an open source project with a protocol spec - I'm not sure that there's any well-used third-party implementations, are there?
moparisthebestmatrix starts with the whole shebang and then you are stuck with it
CognitiveDissonanceOh hey lovetox is here. I love gajim.
moparisthebestand that brings things like "sorry our main server is so slow please move to another server"
CognitiveDissonancegotta go though
dwdBut if there ends up being a bunch of independent implementations, then wholesale changes to the monolith spec are going to be much harder to arrange.
moparisthebestvs xmpp's "we handle 10million+ simultaneous connections and 600+ messages per second no problem" https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/
KevThat does *heavily* depend on your traffic model, mind.
dwdmoparisthebest, Yeah, but I kind of got bored with scaling. I like that we can, but I'm more interested in smaller scale stuff now - you can do a lot more interesting stuff.
moparisthebestsure it's just nice to know it *can*
dwdRight, sure. And it's another strength - you can pick a server built to do massive scaling, or one built for low-bandwidth, or write your own in about 2,000 lines of Python.
KevOr one line of Perl.
raghavgururajan> dwd: But if there ends up being a bunch of independent implementations, then wholesale changes to the monolith spec are going to be much harder to arrange.
Zashor one looooooooong line of sed ;)
moparisthebestif you find yourself rewriting your server in another language in the hope it might be faster you've probably made a wrong turn design-wise
dwdmoparisthebest, Oh, I think 2000 lines of Python will be slower. But I don't have to scale to 10 million users, so I have other criteria for success.
moparisthebest(that was a jab at matrix by the way)
raghavgururajan*ignore the ?
moparisthebestwow I do have to give them props for this page https://matrix.org/docs/projects/try-matrix-now that's far superior to anything we have
KevThey have a much less complex ecosystem than we have.
KevAnd that page is already looking pretty complex.
KevI really need to fix that bug.
moparisthebestreally? if you only judged by https://xmpp.org/software/clients.html / https://xmpp.org/software/servers.html / https://xmpp.org/software/libraries.html you'd probably conclude we barely have an ecosystem at all
KevZash: Unless I'm wrong (which is always possible), Matrix is led by Matrix. They don't have the complexities we do where our 'central org' (I don't have a better description) is community-run by competing projects etc.
ZashKev: Oh boy, let me tell you about Grid, the Matrix (protocol) fork (IIRC).
KevSo I'm just wrong. Fair enough.
ZashKev: But yeah. It's probably comparable to back when Jabber Inc was a thing.
KevJabber Inc was never the JSF, though.
ZashSimilar but different 🤷
Steve Killehas left
Steve Killehas joined
MattJ> If I want to get a reliable xmpp client going on my Mac, I’m going to have to download and compile code, and I don’t actually know which code is the best bet, so chances are I’m going to have to download and compile multiple bits of code before I find one that works.
MattJEr, wrong chat but not I guess
ZashSure would be nice to have that nicer clients.html
KevBe nice to have nicer clients first :D
Kev(Yes, I know Swift hasn't had enough love in recent times. Working on that at the moment, although what form it'll take is up in the air)
wurstsalatZash, very much +1
dwdI am right in thinking Ted Lemon's talking bollocks there, surely? I mean, the Mac desktop clients aren't pretty, but there's a few that exist and they're all in binary form right?
KevI've no idea which room this is referring to.
KevBut it is certainly true that XMPP clients on Mac tend to be precompiled.
ZashKev: IETF list
dwdKev, MattJ's quote is from a mail by Ted Lemon on ietf-disgust
AndrzejBeagleIM is for macOS and is distributed in binary form but if you wish you can compile it yourself
Zashdwd, Kev: Have you seen https://gist.github.com/mar-v-in/8a9a578d2137a0196744a32abf6aa0eb/ ?
KevIf that's the same as the old mailing list post that suggested we must not know what we're talking about, yes.
ZashI don't know about that
KevI thought there was some line in it about only understonding how we could have written it if we didn't understand the area.
KevI might misremember, or it might be a different post. Will see if I can read it tomorr.w
dwdNo, this one just says it's badly written, and was proibably written solely to prove him wrong.
dwdIn any case, *my* main problem with MAM-FC, currently - beyond it needing a lot of editing work - is that there's no way for a server to distinguish between a client updating its conversation view and a client paging through a conversation. RSM simply doesn't provide that, and the result is it gets a bit weird and broken, or else plain inefficient.
lskdjfdwd, in that gist there is a whole page of arguments on what the person thinks are issues with MAM-FC. It's not fair to pick out one sencence you didn't like to be able to say "whatever". It would be good to hear why you think that the issues raised in the gist (e.g. paragraph 3+4) aren't actually issues.
moparisthebestKev: speaking of misunderstandings another reminder for the xep-0001 update :)