XSF Discussion - 2020-10-06

Can participants fetch MUC-registered nicknames of other participants?

Will those appear in the member list?

Admin/owner list

That's probably way underspecified. But it would make sense

Since prosody is the only implementation that even has registration ask MattJ?

MattJ proposed to send all registered participants that are not an occupant with unavailable presence.

(one more place to fetch nicks yay)

IMHO, sending a bunch of unavailable presence with a join shouldn't break anything

Shouldn't...

But yes that probably makes sense

pep., "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

In my head I have a draft thing for MUC join flags to opt into things like this

and 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)

Uh. Like muc/sub

MattJ: also a flag to not send occupant presence and a roser-versioning-alike thing for the participants?

MattJ: there are other places where a client can fetch nicks / display name that a MUC doesn't have access to

right?

pep., oh, sure

Daniel, 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) ✏

I still think that improving MUC is worthwhile. MIX has become a significant engineering effort.

Implementing it on the client side is probably easy

but for me the biggest issue with MUC is reconnection/reliability

before we can solve that it feels a little pointless to waste time and energy on other improvements

but I understand that different people have different priorities

and/or that work on one improvement doesn't block improvements on other fronts

Daniel: did you make any progress on the per-MUC push registration?

i even removed the code again

because it was causing some weird edge case bugs

where the server was maybe at fault

and nobody had implemented it

"weird edge case bugs" is the long form of "MUC"

well 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

What happened of 410 on s2s?

I 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

MattJ, any hint about my first question btw ✏

not on s2s but having your server do it?

because 410 on s2s would just be regular ping, no?

yeah, servers doing "410"

Whatever it takes to keep the link on. Which is also gonna be a problem for MIX anyway

didn’t eta want to come up with a thing

dunno

MIX has the additional problem that there is no plan for recovering from s2s outages.

yeah

MUC is self-healing, more or less, once you rejoin

i've heard matrix has something for that

MIX... good luck.

well your joins/leaves are IQ based so you know if that was succesful

We also have the same problem with MAM.

and then you might just lose messages

Because apparently, combining "give me everything I missed" and "enable live delivery" is a HARD problem

pep., from example 131 in XEP-0045 it looks like the affiliation list includes the nick, so yeah

Ah, thanks. I missed it indeed

MattJ, does prosody already include that?

Yes

Just found the test: https://hg.prosody.im/trunk/file/tip/spec/scansion/muc_register.scs#l397

Daniel: yeah I have half a protoxep about automatically reconnecting to MUCs that I never finished

Hi, I've refreshed library in libraries.json, but xmpp.org hasn't been synced. Could someone update xmpp.org? The library is libstrophe.

pasis: It was merged though, right? I think I did

yes, it's merged, just doesn't appear at xmpp.org

Yeah docker things probably need a push

they need a pull :-X

:P

joking aside, will do

updated

btw. 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

vanitasvitae, ah, I missed your approval on those, as I was on vacation during that time

will tag them so that I process them later tonight

thanks for the ping

nice 🙂

thanks for being an editor ❤️

and I didn't really help :x

it works now, thanks :)

(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.

dwd, I mean it does peter out near the end; the only useful thing in that series is the whole "sponsoring server" model

(which you could implement with XEP-0045 today and a custom MUC component, and I indeed might one day)

eta, Ah, yes - you had a hybrid model between XMPP's single authority and IRC's model of every server has to be trusted?

dwd, exactly -- you have a quorum of trusted servers that use some consensus algorithm (Raft / Paxos)

which is less crazy than Matrix's "fully decentralized" model (which I don't see being viable) ✏

(blog link?)

eta, There's some work around on partially trusted consensus algorithms, too. Kind of like BFT algorithms but each server might have different legitimate aims.

pep., https://theta.eu.org/2019/10/10/nea-federation-design.html

thanks

eta, 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.

dwd, very potentially! I never really went anywhere with this; it was just an idea

what could be interesting is just to piggyback of something like etcd, which already handles the distributed state

eta, Well, you could start with a simple Raft implementation, for exploratory purposes.

etcd is just a Raft implementation on top of a k/v store, isn't it?

eta, 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.

Shell, yeah

dwd, yeah, I mean you only need consensus for things like the room member list

Am I misremembering Raft, or isn't it a leadership-election thing? So fails if you need to continue functioning in a split situation?

eta, ... maybe? I'm not sure that needs consensus until the point where a member is more than a mere passive observer.

dwd, no, sure

I meant more bans/voiced users/etc

Kev, It might have leadership, but it survives partition. It is not, however, eventually-consistent, so an orphaned member ceases to be available.

That is, I believe, what I intended to express. The majority split functions, the minority split doesn't.

Kev, the thing is you can just queue messages in the minority split until it rejoins

eta

(Sorry, dev version of client)

aha :)

Kev, 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.

eta: 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.

Kev, <message/>

I don't know Raft nor Paxos. Why would a minority not continue working on its own? redo elections etc.?

Resources I can read?

pep., https://raft.github.io/

because the minority can't know that what it does is compatible with the state of the majority.

dwd: 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).

pep., Have a look at "CAP Theorum", as a good general start point.

pep: 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.

Kev, Broadly, this is true for almost every consensus algorithm that eschews eventual consistency.

Right.

Kev, right, your use of minority / majority "only" makes sense when you try to merge back :p

Thanks for the pointers

Kev, I don't see how you can do split riding though

Kev, But also, I don't think the netsplit op attacks are possible if you don't have an eventual-consistency style.

if you're in the minority partition, disallow all state changes

eta, Not just state. Message reordering can lead to some interesting problems.

Right. That (eta) obviously avoids the complications, at the cost of degraded service. But note that 'state' here includes message publishing.

And when I say "interesting", I mean in the sense of people dying.

?!

Just DAG everything?

eta, Not that context actually, but yes.

wait, so explain how message reordering is problematic?

"Is the patient breathing?" "Yes" "Have you checked for spinal injury?" "No". Rearrange for much fun.

right, but you can't flip the yes and the no here

assuming the asker and the responder have a netsplit between them

because the behaviour in event of partition is to queue

eta: is your blog on planet ?

No, but if the "Yes" follows "spinal injury" people get pretty confused very quickly.

Zash, don't think so

eta: you can get nice reordering effects if there is a third party reading, and they have intermittent s2s issues

My (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.

Kev, hah

Ge0rG, 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.

dwd: Our conversation here is a DAG. It's just a very specialised case :)

._._._._._._._.

Kev, Yes, yes. Have a sticker. :-)

Kev: is it really? Each message is either a root or a reference to some earlier message.

if you *really* cared about message ordering you could replicate messages in the raft log

Ge0rG, A linear graph is a proper subset of a DAG, I think he means.

but that would add quite a deal of latency

dwd: Honestly, a decent sticker would brighten up my day Quite A Lot right now.

dwd: yes, that's what I conlcuded from the message as well. My point is that this conversation is not a linear graph.

Some people want ./·_./·_./·_. :x ✏

And not a full dag

pep.: is that morse code?

drunk morse?

Ge0rG, Morse did drink a lot.

Ge0rG: I'm as surprised as the next person that my joke doesn't stand up to scrutiny.

Kev: sorry

Kev, It's been rejected at peer review stage, but is still available as a pre=print, so I guess you win?

Academic journal peer review is a process I will be very happy not to go through again (on either side).

I suppose normal people are not deep into partially ordered histories, right?

Georg - 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.

Ge0rG, it's supposed to represent a special shape of tree :p Dunno if that has a name

https://ppjet.bouah.net/tree-foo.png

Kev: 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

Ah. Yes, I think a UI needs to de-DAG it in order for it to be reasonably understandable.

eta, 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.

(Basically meant to say some people want to be able to reply to a single message)

Kev, Or as pep. suggests (I think), Slack-style "threading".

Are we talking about threading or about message history consistency?

I 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.

pep., FWIW, I wanted to do Slack-style threading by spawning off a new chatroom as a child of the containing conversation.

dwd, I hear that's how rocketchat worksss-ish?

I've never used it

Kev, Also the whole point of CAP is that you can't solve all aspects of it.

I wanted to do Slack-style threading by spawning off a new message node within the channel.

dwd: Yes, thus the "(yes)" to denote that I realised.

pep., I... don't know. I do know some people who do a lot with Rocketchat though.

Kev, 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.

Sometimes I should just not write things. :-)

eta, 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.

You are probably right that I'm not expressing things in an observer-considerate way.

I'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.

Yes - no need to conider Byzantine fault tolerance, but you probably so want to go the eventual consistency route for most things.

I hadn't realised it, but reading eta's article I'm starting to think I'm in the middle of re-inventing Matrix.

Kev, 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?

dwd, yes

Yes.

the fix was "improve the merge algorithm"

so the channel with the earliest creation timestamp wins

Well, that was one of the fixes. I've also seen (maybe not recently) disallowing channel creation during a split.

Oh glob not merge algorithms

You can't *not* have merge algorithms of some sort, if you want eventual consistency.

You 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.

eta, 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.

eta, Most notably, because our distributed system is a heterogeneous distributed system already.

porn

ah, that is porn

yes, but uploaded using HTTP Upload !

yeah, which meant I clicked on it

and now it's on my screen and I can't delete it

thanks dino

quick quick send new messages

Message Moderation to the rescue?

Scrolling, scrolling, scrolling.

luckily I waited before clicking

Get them wagons rolling.

got a nice preview on Movim :D

but yeah, deleting images in dino would be nice

Zash, I think allowing a user to stop displaying a picture would be nice nonetheless :/

Some clients will just auto load images

vanitasvitae, indeed

actually it's the best way to wake up a channel it seems 🤔

hahaha

yay, it's off the screen now

Good, now we can go back to sleep

Pretty sure I enabled moderation here, so you can go in and delete it from the archives even

pfieuw, now let's go back to normal

At least we're considered a worthwhile audience for porn spam.

You can't solve social problems with technical means. If you block images, they'll send ASCII porn. Or illegal text content.

Zash, but isn't it just converse that does that

only XEP pr0n is allowed here, I like reading 0060 for example

that's the good stuff

guys, follow my OnlyXEPs account!

edhelas: you pervert!

yeah, I love those Romeo & Juliet stories

While there is some activity in here: in 20 minutes we have a SCAM meeting in xmpp:scam@muc.xmpp.org?join and we're talking about Summit. Please join if you want to follow and/or have ideas on the organisation side of things

pep., thanks for the heads up

I have a proposal 🙂

porn

Porn again? This time moving pictures?

Yes

Better moderating support in clients is going to become more desirable.

EG: make a room temporarily moderated, hand out voice, stuff like that.

and XEP-0425

porn

porn

Hi all

I was wondering, what is the *fundamental* difference between XMPP and Matrix?

Great question :)

Fundamental from an end user experience probably not

I think the fundamental difference is that XMPP is based on routing stuff, and Matrix is based on distributing stuff

Like design principles, target use-cases, future roadmap etc..

CognitiveDissonance, 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)

Ah, routing vs distributing seems like a core difference.

Also, is matrix completely web-based?

this is why Matrix servers need more resources to run; because they spend a lot of energy doing this replication algorithm

Define web based.

whereas XMPP messages are simple and easy to route

Daniel http

Yes it uses http.

> easy to route /me giggles

Daniel What about xmpp?

but if "http" is your criteria then XMPP is also web-based

c2s *can* be http

because it can be used over http

s2s is tcp

or at least we haven’t speced out a way to use s2s over http

i guess we could

why tho

So in terms of design principles like modularity, simplicity and extensibility, what is the diff b/w them?

Daniel Hmm, I always seen only xmpp://foo and not http://foo, for c2s

jonas’, well I was just answering a question.

XMPP 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

but you might want to run servers behind more restrictives firewalls

on your raspi or something

Running servers in the browser has been discussed in certain server projects before

Daniel: I see.

moparisthebest Point.

* good point

CognitiveDissonance, so natively XMPP uses a TCP socket, but the BOSH (bidirectional streams over synchronous HTTP) extension lets you use it over HTTP

Sp matrix is a monolithic system right?

(almost all popular servers expose that as an option for web clients)

eta, CognitiveDissonance also websockets

yep, that too

I expect *very soon (tm)* xmpp c2s and s2s to start working over QUIC as well

eta Daniel Ah BOSH makes sense. Btw, xmpp server doesn't *require* web server right? matrix seems to rely on web server.

CognitiveDissonance, not at all!

you might want one for HTTP file uploading (XEP-0363), but it isn't a hard requirement

I see.

Also, in DNS records, I notices xmpp has only SRV records, where matrix has only A records.

that's because matrix uses /.well-known

CognitiveDissonance, you need A/AAAA records for SRV to make sense

XMPP also has TXT records for some connection methods...

boon or a bane?

Matrix uses SRV too

again I expect *very soon (tm)* XMPP to start using http-svc/srv2 records or whatever the latest name for those are

moparisthebest: don't you dare!

Zash, required for sni+alpn encryption!

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

(plus other things etc)

Do not want

i am scared of http and web tech stuff.

that's the best thing about XMPP, even if you don't want it I can still have it and vice versa :D

Too many security issues

CognitiveDissonance, to be fair that's just "computers"

CognitiveDissonance, To be clear, Matrix need not suffer from those since it's not like it runs in the browser. ✏

CognitiveDissonance, It just uses HTTP and JSON as its substrate layer, like XMPP uses XML. And XML has its own set of amusing security issues.

"laugh"able!

dwd hmm, AFAIK, even riot/element desktop client is a web stuff via electron.

CognitiveDissonance, Sure, the implementation of the clients is all web tech. But in principle it need not be.

dwd. I see. I have seem in wikipedia that xmpp is a text-based protocol like IRC. what does mean?

CognitiveDissonance, There are, I think, Electron-ish clients in the XMPP world. Certainly browser based ones.

CognitiveDissonance, it means that some bytes are not allowed in the streams

doesn’t matter in practice

CognitiveDissonance, XMPP operates by exchanging XML fragments over TCP, not text. Matrix operates by exchanging bits of JSON over HTTP.

IRC operates by exchanging bytes over TCP, better hope you guess the encoding correctly!

(Favourite thing about IRC is that the case-folding for usernames is based on whatever keyboard layout the developer happened to be using).

I was confused about "text-based". XML is not a plain text?

(dwd, wasn’t it the swedish 8-bit latin encoding thing?)

jonas’: finnish

CognitiveDissonance, it is as much plain text as JSON is

Zash, ah, right

CognitiveDissonance, It's generally textual in nature, but it's not plain text as such.

(I mixed that up with mysql, that was swedish)

if anything XMPP/XML and Matrix/JSON are much more "text-based" than IRC because the encoding is actually defined

dwd: Ah, I am getting the fundamental difference now.

Matrix exchanges JSON over http and XMPP exchanges XML over tcp.

(over http over tcp/whatever atrocity google thinks of)

If I put a VS (versus) in between ....

mainly yes, but more generically XMPP exchanges XML over (a stream)

CognitiveDissonance, 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.

it's mostly TCP but it can be Websocket or a BOSH session today

QUIC or whatever else tommorow

moparisthebest, In fairness, plain TCP is rare since we're always using TLS.

right I didn't mean *plain* TCP but good clarification

http is stateless and tct is stateful?

CognitiveDissonance, Broadly meaningless. Matrix has state in its sessions.

I see.

CognitiveDissonance, 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.

"HTTP runs over TCP anyway" eh not so much anymore, http up to 2 does, http 3 does not

in a similar way that future XMPP won't have to :)

what?

http is application layer right? it requires tcp?

http3 runs over QUIC which is like TLS but over UDP

quic??

https://en.wikipedia.org/wiki/QUIC

nice

(good thing we didn’t have DTLS…)

https://en.wikipedia.org/wiki/HTTP/3 etc

Matthew 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.

Thank you all folks!!!

I appreciate it.

jonas’, DTLS is quite different than QUIC

moparisthebest, I don’t care

I mean, finding a client or server that does XMPP and nothing else is *hard*.

it's akin to UDP vs TCP, you can't just drop-in replace one with the other, different use cases

You mean RFC 6120 only? Impossible, I suspect.

Kev, I was thinking 6120+6121, which is in principle possible.

dwd: That is actually. Start minimal and extend. Keeps things simple and modular.

Sorry, 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[01] and nothing else, but not shocked.

*actually good

try finding a browser that just does http

moparisthebest, Ooooh, I'm going to use that next time someone does the "Too many XEPS!!!111" argument with me.

HTTP has too many RFCs!

To 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?

Broadly, yes - I don't know how else we could have built it but start with a common base and add bits.

raghavgururajan I was looking for that difference in xmpp and matrix.

Matrix 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?

matrix starts with the whole shebang and then you are stuck with it

Oh hey lovetox is here. I love gajim.

and that brings things like "sorry our main server is so slow please move to another server"

gotta go though

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.

vs xmpp's "we handle 10million+ simultaneous connections and 600+ messages per second no problem" https://www.process-one.net/blog/ejabberd-nintendo-switch-npns/

That does *heavily* depend on your traffic model, mind.

moparisthebest, 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.

sure it's just nice to know it *can*

Right, 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.

Or one line of Perl.

> 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. +1

or one looooooooong line of sed ;)

if 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

moparisthebest, 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.

(that was a jab at matrix by the way)

?

*ignore the ?

wow 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

They have a much less complex ecosystem than we have.

And that page is already looking pretty complex.

Kev: ORLY?

Z

I really need to fix that bug.

really? 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

Zash: 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.

http://screenshots.debian.net/packages?search=xmpp&show=with

Kev: Oh boy, let me tell you about Grid, the Matrix (protocol) fork (IIRC).

So I'm just wrong. Fair enough.

Kev: But yeah. It's probably comparable to back when Jabber Inc was a thing.

Jabber Inc was never the JSF, though.

Similar but different 🤷

Fair.

> 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.

Er, wrong chat but not I guess

Sure would be nice to have that nicer clients.html

Be nice to have nicer clients first :D

(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)

Zash, very much +1

I 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?

I've no idea which room this is referring to.

But it is certainly true that XMPP clients on Mac tend to be precompiled.

Kev: IETF list

Kev, MattJ's quote is from a mail by Ted Lemon on ietf-disgust

Ah, ta.

BeagleIM is for macOS and is distributed in binary form but if you wish you can compile it yourself

Zash, wait, what do you know about grid

https://mailarchive.ietf.org/arch/msg/tools-discuss/21-hD287xlxBkskiWxPl5vX6f8I

I wonder at what point I unsubbed from ietf-disgust. I used to be subbed, but realise now I've not seen a mail for years, so I probably made a (rare) Good Life Choice at some point.

eta: I know someone wrote a long rant about how insecure Matrix is, then went on to make their own fork of it.

dwd, typo? :D

Zash, yeah, Max

hrm since when was XMPP considered part of the #Fediverse ?

https://the-federation.info/ lists XMPP, ergo XMPP is part of the Fediverse.

yep that's where I noticed

Now proceed to accept this circular logic as truth. Thank you!

I thought Fediverse was just ActivityPub based stuff TIL

I thought it dated back to OStatus, but I'm not so sure.

I think it depends how you define the Fediverse

Diaspora is also considered part of it and doesn't do AP either

So XMPP fits the definition of being federated and being able to do social networking

Is Email part of the Fediverse? :D

if XMPP is then I'd have to argue SMTP is too

there is social networking stuff built on XMPP, it's probably fediverse

moparisthebest, EMail used to be before Google took it over...

Zash: Is there a homepage for Grid?

moparisthebest: Yes, SMTP and XMPP are fedearted protocols.

yea I knew that, just not that every federated protocol was considered part of the "fediverse"

Please tell me they have usenet in there.

usenet distributed, not federated!!!!!!!eleven

a ton I've never heard of but no usenet https://the-federation.info/#protocols

zot? dfrn? all have more servers than the pitiful 53 XMPP servers and the 1 SMTP server

strangely, not gmail.com

Zash, I don't think it described itself as federated - but nor did email.

possibly relevant xkcd https://xkcd.com/802/

Zash, But you can post a message to any NNTP server and it ends up on all of them somehow, right?

dwd: Just like Matrix!

dwd: "usenet is distributed, not federerated" was what I meant to write, before my sleepy brain decided to change the sentence structure in the middle

To me it looks like a "much spinning" site

Maranda: https://www.youtube.com/watch?v=ldK1gQSSTSo

😂

dwd: You know I'm interested in MAM-FC too ;)

dwd, Kev: Have you seen https://gist.github.com/mar-v-in/8a9a578d2137a0196744a32abf6aa0eb/ ?

If that's the same as the old mailing list post that suggested we must not know what we're talking about, yes.

I don't know about that

I thought there was some line in it about only understonding how we could have written it if we didn't understand the area.

I might misremember, or it might be a different post. Will see if I can read it tomorr.w

No, this one just says it's badly written, and was proibably written solely to prove him wrong.

In 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.

dwd, 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.

Kev: speaking of misunderstandings another reminder for the xep-0001 update :)