XSF Discussion - 2017-10-24

Yes, and apparently the take away for the moment is someone does not like your mascote

mascote?

yup saw that, I answered on the discussion already

at least people are not talking about Matrix :p

Great success

is matrix still alive?

I still remember the claim "Insanely scalable and performant next-generation server (Dendrite) on the horizon" and waiting patiently

soon

You get a ruby thing that needs 2 gigs of memory for a few users

RAM is meant to be used

nah

it's in Go

I mean the current server

the current is in python

Same same :P

yes, crap

and then they chose another crap

every server in Go I used is leaking and unstable as hell

damn, I cannot even read the MIX XEP, yet I have to implement it, wtf...

I know that feeling

zinid, You're implementing MIX? Our implementation still doesn't entirely match the XEP. Too many things don't work well in practise.

dwd: I implemented the very first version, it's outdated of course

and looking at the current XEP I'm losing motivation, it's overly complex

Maybe we can just fix MUC.

zinid, Some parts are fine. Others get a bit weird, mostly around proxy vs real jids.

Ge0rG: Make me motivated to work on mod_minimix or whatever I called it. Makes you join MUCs with your bare JID. I forget what parts got weird.

Ge0rG: I also tend to think it's easier to fix MUC

or implement "simple" muc

Zash: write to standards@!

Ge0rG: Implementation first!

Ge0rG: Technically not requiring any standards yet. Protocol doesn't change.

Zash: joining with a bare JID is a protocol change.

Does MUC forbid that?

I'm pretty sure it does

really?

okay, I'm not sure.

Arbitrary JID limitations should go away

No, it doesn't.

What if a server wants to join a room that doesn't have a node? :)

Oh, room jids have to be of specific forms.

what if a server wants to join a room that runs at the bare JID of the server?

dwd: you can join chat.yax.im as a MUC.

Ge0rG, You're not making the argument you think you are there.

dwd: I'm not sure I wanted to make an argument at all

Ge0rG, First bullet-point in XEP-0045§3.

dwd: that is not normative

Ge0rG, What? Why not?

> For the sake of backwards-compatibility [with] groupchat 1.0

Zash, That is indeed the rationale for the requirement stated.

dwd: it merely states a result of some historical quirks, it doesn't require that a MUC MUST have that form.

dwd: How does that translate into bare host rooms being forbidden?

Ge0rG, You think unless it uses a mystical incantation of RFC 2119 you can ignore it?

dwd: I think that "well written" and "XEP 0045" don't belong into the same sentence.

Zash, It says they're requirements. Seems they're probably required. Whether that's a good idea or not is an entirely different matter.

dwd: What, and here I was just grepping for MUST and ignored everything else! :)

yeah, this is very important problem: should a room have node part? it should be resolved asap!

dwd: But does that mean you need to support room@host or *only* room@host?

dwd: there is no requirement that the room name must be non-empty

Zash, It's there as a statement of fact: "Each room is identified as a "room JID" <room@service>", so I'd say if a room cannot be so identified it's not conformant to the spec.

Ge0rG, Yes there is, the local-part of a jid cannot be zero-length.

Zash, I'm not saying this is a sensible requirement, or that it wouldn't work any other way. I'm merely saying that this is what the XEP says.

except the XEP is not very clear in its wording

Ge0rG: "each room is identified"

isn't this clear?

Zash, But anyway. It says nothing I can find on the subject of what the occupant's real jids are (though it infers they're full jids a few times, it never states this as a requirement).

So MUC at bare host aren't rooms, but special magical hidden places for cool people only! :)

of course, "MUST be of <room@server>" would be clearly, but XEP authors prefer very long sentence with cryptic words :)

dwd: Shiny

Zash: XEP authors are people, too

dwd: So nothing prevents a server from just sending one join stanza, then keeping track of which local resources have joined, forking incoming groupchats as needed

Zash: so you are moving MSN from the MUC to the user's server

zinid, "Each room MUST be identified as" would be longer, not shorter. But FWIW, I really hate littering a document with RFC 2119 language, and prefer to use it more sparingly to highlight more subtle cases.

Which also means it can easily do MAM without a mess

Ge0rG: Pretty much, yes

Zash: and MUC-PMs

But it would probably break biboumi in surprising ways

Zash, More or less. But presence would remain a mess. And if you avoided that, you're getting very close to MIX.

dwd: Why I called my draft code "minimix" :)

Zash: write it in a way that you can plug it into MUC or into the server, and fix nick changes etc.

and presence priority.

dwd: I just wanted to say that would be great to have shorter sentences with simplier words, think about non-native speakers

dwd: I recall there is even RFC stating that

zinid: there is a reason for so many Shakespeare references in the XEPs.

zinid, Yes, I agree simple sentences are better.

Ge0rG: to promote English culture?

zinid, Even though its an American doing so, most of the time.

zinid, I'd be tempted, myself, to use Tolstoy. More characters, for a start.

dwd: but this is clearly your move :P In other RFCs are just used Bob and Alice

dwd: that reminds me of http://idlewords.com/talks/website_obesity.htm

zinid, Also, I read War and Peace (and various other Tolstoy, Chekov, Dostoyevsky) back in my teens and cannot remember the characters anymore.

dwd: lol, I didn't even read them :D

zinid, Well, I did read them in English, in fairness.

I think I skipped War and Peace in highschool, but Anna Karenina is still one of my favorite books.

zinid: what servers in Go gave you trouble? One of Go's features is that it makes resource leaks hard, so that surprises me.

SamWhited: ipfs

https://github.com/ipfs/go-ipfs/issues/4312

one of the point is memory leaking

gc performance sucks also

How did they manage that? Go's gc can correct a 50 gig heap in under 10ms in most cases

*collect

is it from Google's advertisement? :)

Complex systems run into memory leaks more or less easily no matter what the language, no?

No, it's from data I've seen in prod.

Holger: we have ejabberd with several month uptime without leaking for example

yes, the consumption might be high, but not leaking

zinid: Yes sure, I'm not saying all complex systems are leaking :-)

All complex systems are leaking, just at different speeds ;)

But if you get something wrong, i.e. if you accumulate references to blobs over time, no GC in the world will save you from that.

I'm reasonably sure none of these things have anything to do with the language though; you can't have a traditional memory leak in go because there's gc, but if you always add things to an append only list and keep a reverence forever then obviously there's nothing the language can do

You can leak resources in Go, eg. forget to close a file descriptor or have an infinitely looping coroutine, but defer/close makes that pretty hard to do.

the point is that it doesn't matter how you leak it

also, would be great to have tools

to see where is leaking

and looking at IPFS guys there are no such tools :)

It does if you're going to blame the language, because if it's a bug I'd like to fix it. What kind of tools?

There is extensive tooling for that

https://github.com/ipfs/go-ipfs/issues/3532

one year already, with several duplicates

you might want to suggest them the tool :)

Tooling for what, exactly?

I will, that sounds like the ipfs people just don't know what they're doing. Pprof can ve used to monitor the heap size, and all Go binaries have built in gc logging (you can set an environment variable and they'll dump runtime statistics)

I'm not sure Go servers will typically use goroutines in a similar way to Erlang processes. If so I'd want tools to query resource usage and state of individual goroutines (or groups of them), to modify the state, to kill them; or I'll return to Erlang :-)

I want tools too

Holger: I don't think it makes sense to do that, they're much lighter weight and you might have multiple per task, but you could.

Zash: Says the Lua programmer ... :-)

SamWhited: Much leighter weight than what? It makes a *lot* of sense in Erlang.

It doesn't make sense in Go, I mean. Go's coroutines are lighter weight.

Than what :-)

If you're a server, would you typically use a goroutine to handle a client connection?

Yes, maybe several.

If so you will of course take advantage of being able to introspect that at runtime.

Yes, it's certainly not as easy as in a dynamic language, but there are process monitoring tools to show you long running goroutines

Monitoring is common, manually killing or changing the state isn't, it's not a dynamic language. Although there are debuggers that can do that, I guess.

Well, monitoring is as easy, mutating isn't.

supervision can be implemented in any language

but seems like everyone copies idea of "goroutines" and think they got Erlang

But everbody knows that you need overpriced special experts for Erlang and C++ projects.

lack of runtime introspection is the stopper factor for me in any such fancy language

They have hype. Go is a bit like Matrix :-)

(Well except that Go is actually successful.)

lol

fair remark :D

Matrix is successfull, there's thousands of subscribers on their chatrooms

Shun the hype!

edhelas: they have even me there!

but I don't use Matrix...

edhelas: Is that an accurate indicator of success?

zinid you're a spy on cover sent by the XSF ?

edhelas: I used to be a spy once (or twice)

I really wanted to like matrix, but the basic premise of the protocol is crap and they built it in an unsustainable way (and then were surprised when the money dried up)

SamWhited: Why did you want to like it?

"unsustainable way"? what do you mean? like they don't have enough resources to develop/promote/etc it?

Zash: So that I could have something that was an interoperable and federated standard that wasn't our broken crap, unfortunately it never became the alternative I hoped it would

zinid: they had enough resources, until they didn't. It's unsustainable because they expected one company to pay them for full time developers forever

Ah

And we saw how that works out… not that they couldn't continue it in a more sustainable way now, but they seem to expect to still be able to be paid full time for it.

What irks me is that it's just one implementation - done by the same people that develop the standards.

well the idea that a single company controls a *federated* protocol is broken

not sure if it's broken - but it does not bode well.

Yah, I hoped they'd get other implementations later, but it wasn't a healthy ecosystem

what about OStatus/ActivityPub ?

from innovative perspective I used to find Tox even more interesting than Matrix, but it's dead too

There is Ring.cx, but buggy as hell

Ring is interesting but unfortunately their architecture prevent them to have advanced features

like history, sync and profiles

you cannot compare apples and oranges

edhelas: I think it's possible with dumb servers

Aka backup servers

WhatsApp like

Well it scales good

Talking about p2p with servers?

nah

Zash: hybrid

But more p2pish

the whatsapp accounts are bound to the devices

so to sync history between devices, or migrating them they use "backup servers"

Like Skype?

You see, if you have several devices you can synchronize yourself, you don't even need backups

Skype is now a dumb centralized service since Microsoft bought them

Any client dev interested in doing client to client MAM?

but why :D

And if all your devices offline and someone sent you a message, you will request it on login (via Delta from the contact)

edhelas: IIRC they switched it to the MSN infrastructure

So backups might not even be needed, at least for everyone

There is a problem with conferences in such system tho

As edhelas says, Skype centralized a while back, mostly because of mobile devices.

dwd: yes, mobile complicates everything, especially ios restrictions