kinetikHi, I'm curious if there's an XEP out there that deals with a tree-like structure for conversations, where each response is either root level or is in response to some other message
sabryhas left
neshtaxmpphas left
neshtaxmpphas joined
kinetik(sort of like how reddit structures things, but without all the other stuff)
BASSGODhas left
millesimushas left
restive_monkhas left
sabryhas joined
SamIt's built into the RFC, but nothing uses it as far as I know: https://datatracker.ietf.org/doc/html/rfc6121#section-5.2.5
millesimushas joined
andrey.ghas joined
Andrzejhas joined
restive_monkhas joined
sabryhas left
sabryhas joined
restive_monkhas left
jcbrandhas joined
adiaholichas joined
restive_monkhas joined
restive_monkhas left
matkorhas joined
jcbrandhas left
restive_monkhas joined
adiaholichas left
qwestionhas joined
emushas left
alacerhas joined
stphas joined
Vidakhas joined
adiaholichas joined
Andrzejhas left
BASSGODhas joined
matkorhas left
andrey.ghas left
tykaynhas left
stphas left
alacerhas left
Vidakhas left
adiaholichas left
matkorhas joined
alacerhas joined
adiaholichas joined
adiaholichas left
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Andrzejhas joined
adiaholichas joined
argentumhas left
wladmishas left
Friendly Resident Cynichas left
daagshas joined
qwestionhas left
Andrzejhas left
matkorhas left
matkorhas joined
Friendly Resident Cynichas joined
Andrzejhas joined
qwehas joined
Yagizahas joined
Andrzejhas left
Calvinhas joined
qwehas left
marc0shas left
marc0shas joined
florettahas left
florettahas joined
adiaholichas left
Menelhas joined
adiaholichas joined
Titihas joined
millesimushas left
mimi89999has left
mimi89999has joined
eevvoorhas left
alacerhas left
eevvoorhas joined
xnamedhas left
Sevehas joined
petehas left
Andrzejhas joined
millesimushas joined
paulhas joined
Tobiashas joined
Titihas left
florettahas left
florettahas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
Titihas joined
me9has joined
msavoritiashas joined
ti_gj06has joined
Vidakhas joined
chronosx88has joined
wurstsalathas joined
ti_gj06has left
ti_gj06has joined
me9has left
Andrzejhas left
Vidakhas left
sabryhas left
chronosx88has left
chronosx88has joined
jcbrandhas joined
millesimushas left
Paganinihas left
millesimushas joined
Vidakhas joined
sabryhas joined
Vidakhas left
Vidakhas joined
marchas joined
Guushas left
Guushas joined
Menelhas left
ti_gj06has left
sabryhas left
ti_gj06has joined
xnamedhas joined
goffihas joined
xnamedhas left
debaclehas joined
Mikaelahas joined
marchas left
marchas joined
emushas joined
eabhas left
eabhas joined
norkkihas left
Sevehas left
Andrzejhas joined
millesimushas left
norkkihas joined
rionInteresting. I didn't know it's there but always missed that thing after slack. Definitely something worthing to implement
Sevehas joined
adiaholichas left
fhtesthas joined
adiaholichas joined
Link MauveSome clients use it, I know of at least Movim.
adiaholichas left
adiaholichas joined
MattJThe problem with threading is not really the protocol, but the UI
millesimushas joined
KevJust relying on thread doesn't work very well (like so many things) unless you have complete knowledge, though,.
KevAnother thing we could really do with MAM understanding.
wladmishas joined
Andrzejhas left
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
TobiasOr have MAM support a thread query filter.
KevThat would be MAM understanding threads :)
millesimushas left
xnamedhas joined
TobiasKind of. Can't you already query for other properties like addresses or body text?
ZashImplementation-dependent
ZashNot mandated by XEP-0313
TobiasTrue
ZashThe basic set of fields are all derived from insertion into the archive (archive-id, timestamp, with=to|from depending on direction), not properties of the stanza itself
TobiasBut technically not all that complex to allow querying for stanza properties, considering it ends up in some kind of database anyway.
Andrzejhas joined
ZashYou probably want to have some index over the things you query on
ZashShould be doable too of course
TobiasTrue
Dele Olajidehas joined
marchas left
marchas joined
APachhas left
pasdesushihas joined
adiaholichas left
chronosx88has left
KevQuerying for a hierarchy of thread references would probably not be a very enjoyable SQL statement to write (or whatever).
adiaholichas joined
Andrzejhas left
Dele Olajidehas left
adiaholichas left
adiaholichas joined
millesimushas joined
wladmishas left
wladmishas joined
xnamedhas left
adiaholichas left
mjkhas joined
adiaholichas joined
Matthew (away)has left
Rixon 👁🗨has left
homebeachhas left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
sabryhas joined
fhtesthas left
fhtesthas joined
stphas joined
millesimushas left
chronosx88has joined
restive_monkhas left
karoshihas joined
tykaynhas joined
gooyahas joined
Andrzejhas joined
Vidakhas left
restive_monkhas joined
neshtaxmpphas left
Vidakhas joined
adiaholichas left
millesimushas joined
fhtesthas left
lskdjfhas joined
Andrzejhas left
Andrzejhas joined
sabryhas left
gooyahas left
adiaholichas joined
gooyahas joined
wladmishas left
wladmishas joined
fhtesthas joined
karoshihas left
adiaholichas left
adiaholichas joined
karoshihas joined
Vaulorhas left
rafasaurushas left
fhtesthas left
sabryhas joined
marchas left
marchas joined
Vaulorhas joined
millesimushas left
neshtaxmpphas joined
gooyahas left
gooyahas joined
millesimushas joined
karoshihas left
neshtaxmpphas left
neshtaxmpphas joined
karoshihas joined
ti_gj06has left
marc0shas left
marc0shas joined
gooyahas left
gooyahas joined
jgarthas left
Friendly Resident Cynichas left
karoshihas left
ti_gj06has joined
adiaholichas left
adiaholichas joined
BASSGODhas left
lovetoxhas left
adiaholichas left
lovetoxhas joined
karoshihas joined
adiaholichas joined
Wojtekhas joined
alex11has left
jcbrandhas left
jcbrandhas joined
adiaholichas left
adiaholichas joined
huhnhas joined
huhnhas left
ti_gj06has left
larmaMattJ, I think the thread protocol IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays.✎
sabryhas left
larmaMattJ, I think the thread protocol in RFC 6121 IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays. ✏
KevHowso?
Danielhas left
ti_gj06has joined
adiaholichas left
larmaThreads in Slack and e-Mails is basically something like a collection of replies (including depth with replies to replies in e-Mail).
Threads in RFC 6121 is more like a session (with child sessions). For example, if we do a board meeting in this channel, the board meeting could be a thread and each agenda sub items could be a sub-thread.
larmaIn Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level.✎
larmaIn Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level (except for sub-threads, which are largely independent and also fork of a thread, not a specific message of that thread) ✏
adiaholichas joined
Andrzejcan't we just use https://xmpp.org/extensions/xep-0372.html#usecase_previous for linking messages and building a tree?
karoshihas left
Danielhas joined
larmaAndrzej, 0372 § 3.4 is about adding a reference (aka a link) to a previous message where the original message forgot to include the link, not about having your new message reference an old message.
larma> An example of this might be where a MIX channel asynchronously adds information about references made in previous messages by users. In this case the message MUST NOT contain a body.
Andrzejok, my bad
larmahttps://xmpp.org/extensions/xep-0461.html would have the correct syntax, but is specifically not meant for creating threads but rather for telegram/whatsapp like replies
larmaBecause it's close to impossible to build the thread feature in a backwards compatible fashion
rafasaurushas joined
Kevlarma: Right, the 'not sending to the channel' thing is Slack/Discord/Guilded/etc.-ish. I'm not convinced the same is true of email - they're all still at the same level logically. My intention with MIX was that threads would go off on their own node within the room.
larma"Best" way is probably to not show the thread to non-supporting clients...✎
larma"Best" way is probably to not show a thread to non-supporting clients... ✏
karoshihas joined
KevProbably going to be hard to get agreement on whether best is to flood a non-supporting client or to deny them completely. But I think once you've got a community where threads are in use any fallback is going to suck one way or another.
Kev(I'm pro-threads, BTW, in case that doesn't come across)
millesimushas left
millesimushas joined
larmaKev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages?
KevOf course, if you have supporting clients, and you have MAM understanding threads, <thread> is just about enough to get going with.
Kev> Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages?
Yes, it's not going to be very satisfying whatever you do there.
larmaIf you want Slack-like UI, how do you fork a thread off a message that did not carry a <thread> already? RFC 6121 requires the initial message of a thread to already carry a thread id.
Ellenor Malikcould message and thread IDs exist in the same namespace, where a thread ID of a message A being the message ID of a message B is illegal?
Menelhas joined
Ellenor Malikdoes a msg ID facility exist?
larma> The value of the <thread/> element MUST uniquely identify the conversation thread either between the conversation partners or more generally
millesimushas left
adiaholichas left
KevSo we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :)
MattJEllenor Malik: we have at least 4 ways of adding IDs to messages, so I hope we're good on that front :)
wladmishas left
wladmishas joined
Ellenor Malik> Kev wrote:
> So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :)
I think so.
larmaKev, well, I feel the feature that was standardized isn't exactly what people want.
BASSGODhas joined
Wojtekhas left
larmaAlso the specifications are sometimes very vague
Ellenor MalikThe value of the element could be assumed if not specified?✎
Ellenor MalikThe value of the thread element could be assumed if not specified? ✏
wladmishas left
wladmishas joined
BASSGODhas left
larmaAlso reading XEP-0201 again:
> the value of the <thread/> element shall be considered equivalent to a unique identifier for the chat session
Kevlarma: I think that's true of a lot of our specs - that they (deliberately) define the protocol, but not how to use it for particular use cases. Whether that's a problem or not probably depends who you ask, but it does mean three people wanted to produce a threads-based system at the moment, they'd probably end up with four logically incompatible systems.
Wojtekhas joined
adiaholichas joined
wladmishas left
larmaI remember that some client (I think it was Gajim) implemented RFC 6121 threads. All messages in a conversation used the same thread id unless you close the conversation and reopen it. That sounds like what XEP-0201 has in mind, but totally is not what Slack or the likes do.
Wojtekhas left
wladmishas joined
wladmishas left
wladmishas joined
larmaXEP-0201 even suggests color coding the thread information. I can imagine that to work pretty good (a message in thread A has a red bar inn front of it, a message in thread B a green bar and a message in thread C that is a child of A has a red and a blue bar), but again it's completely different than Slack-like
larmaThe RFC 6121/XEP-0201 threads seem more similar to the thread concept of Zulip
MattJAnd many people absolutely hate Slack's threading
KevI think using the same thread for a conversation unless you branch off is probably sane, isn't it?
MattJWhich goes back to what I said earlier - it's mostly a UI problem, not a protocol one
Ellenor Malikthe new threads could be called chains
Ellenor Malikidk
Kev> And many people absolutely hate Slack's threading
I know that's true, but are these people who want a *different* threading model, or just hate threads?
Ellenor Maliki am like, not a standardizer
MattJKev, I've seen both camps :)
MattJe.g. Zulip is crazy about threads, and I know people who love that and hate Slack's implementation
MattJThey're both threading, but very differently done
MattJAnd with this being such a subjective feature, I don't see how we can standardize threading across the ecosystem in any particular way
MattJUnless every client is expected to implement the protocol and UI for every type of threading
MattJ(which is obviously absurd)
Wojtekhas joined
KevHow does Zulip do it?
larmaMattJ, you can easily do the threading of Zulip in Slack, it just needs discipline. The UI of Zulip is better in enforcing things.
ZashCan't you do all kinds of threads with `<thread/>` already?
larmaKev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic, if you create a new message you have to specify the topic✎
larmaKev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic as the message you replied to, if you create a new message you have to specify the topic ✏
wladmishas left
larmaThere is no "root thread" in a channel
wladmishas joined
ZashJust have to pick a style and be consistent. So it's impossible.
millesimushas joined
larmaZash, I guess the problem is that <thread> doesn't really define how to do things. At that makes it IMO useless in a federated environment of different clients.
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
ZashYup
larmaThere are a few things though that don't work with threads.
wladmishas left
wladmishas joined
larmaOr at least not sensible
larmaYou could just make <thread> behave as <reply-to>, that is, every message creates a new thread and that new thread has the thread id of the message it replied to as a parent thread id. This would allow e-Mail like thread trees (where a message has a parent message and not a thread a parent thread) and Slack-like off-threads. If you want to make it easier, pick your thread id to always be your message id, so you spare one id. Make it even easier and remove the <thread> alltogehter and just have a <parent> that references the message id instead of thread id.
edhelasmovim is doing that :)
wladmishas left
wladmishas joined
larmaAre you also picking thread id = message id?
Ellenor MalikThread id = message id would mainly make it easier to search for messages threaded up to a given message id
edhelasno, those are different things afaik
larmaEllenor Malik, it also means you have to handle one id less, we already have a bunch of ids on every message, so not adding another one would be a good idea.
ti_gj06has left
adiaholichas left
ti_gj06has joined
wladmishas left
wladmishas joined
adiaholichas joined
millesimushas left
Menelhas left
millesimushas joined
xnamedhas joined
ti_gj06has left
Wojtekhas left
BASSGODhas joined
ti_gj06has joined
Wojtekhas joined
marchas left
marchas joined
Kevhas left
Steve Killehas left
marchas left
Steve Killehas joined
Kevhas joined
marchas joined
xnamedhas left
marchas left
marchas joined
adiaholichas left
florettahas left
karoshihas left
karoshihas joined
adiaholichas joined
ti_gj06has left
ti_gj06has joined
xnamedhas joined
chronosx88has left
chronosx88has joined
florettahas joined
xnamedhas left
marchas left
marchas joined
robertooohas left
robertooohas joined
marchas left
marchas joined
robertooohas left
robertooohas joined
Wojtekhas left
harry837374884has left
harry837374884has joined
adiaholichas left
marchas left
marchas joined
matkorhas left
argentumhas joined
matkorhas joined
karoshihas left
florettahas left
Paganinihas joined
millesimushas left
florettahas joined
sabryhas joined
alacerhas joined
moparisthebestso I've read https://datatracker.ietf.org/doc/html/rfc7712 and https://xmpp.org/extensions/xep-0344.html but one thing remains unclear:
you got server A accepting s2s from server B, server B sends a certificate for sasl external that is not signed by a CA so A doesn't immediatly trust it, is the solution to immediately go for dialback? or has anyone considered using POSH or DANE in this case?
I'm thinking it'd be secure to "get all hashes that can be used for that domain" and check that the certificate matches at least one of them, in which case you offer SASL EXTERNAL and never do dialback?
cc dwd and Zash since I know they've worked on this, though looks like dwd is not currently here :/
qwehas joined
Calvinhas left
Calvinhas joined
karoshihas joined
moparisthebestif you squint *real* hard, that's *almost* what is said by https://xmpp.org/extensions/xep-0344.html#samecert including DANE+POSH in the lookup, just skipping the actual connecting step
fhtesthas joined
sabryhas left
ZashI don't understand the question.
moparisthebestZash, tl;dr how to authenticate incoming S2S certificate using DANE/POSH without dialback
ZashThe implementations I did do all the lookups and use that, yes.
ZashI.e. for DANE it does SRV and then TLSA lookups for each SRV
fhtesthas left
fhtesthas joined
moparisthebestand just trust the connection if any TLSA record matches ?
ZashSame check as for outgoing, yes.
moparisthebestwithout actually making outgoing XMPP connections ?
ZashCorrect
moparisthebestexcellent, that seemed secure and the right thing to do, but it's not actually written down anywhere is it ?
millesimushas joined
ZashI think that's what the DANCE WG is about <https://datatracker.ietf.org/wg/dance/about/>
ZashUnfortunately I don't have the energy for IETF
reimarhas joined
moparisthebestah, indeed that looks right, thanks!
moparisthebestI'd be happy with just a best practices XEP
ZashThe Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, like kinda like the backwards OCSP✎
ZashThe Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, kinda like the backwards OCSP ✏
moparisthebest> TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS)
moparisthebestthat *might* be what they are after there
ZashYes
ZashAlso, this kind of thing was implemented in Chrome once upon a time! (In the other direction tho)
marchas left
marchas joined
BASSGODhas left
BASSGODhas joined
moparisthebestwe also used to have HPKP but that went away too :(
ZashWasn't that a huge footgun?
fhtesthas left
moparisthebestI mean, no more than DANE or DNSSEC in general is I guess ?
ZashAs in, didn't it permanently burn the domain if you messed it up?
moparisthebestno, only for the TTL
moparisthebestcourse if you made the TTL very long, well your bad
ZashI don't remember, what were the recommendations?
millesimushas left
ZashHSTS TTL recommendations tend to be like 6 months or more AFAIK
moparisthebest> Note: These examples use a max-age of two months and include all subdomains. It is advised to verify that this setup will work for your server.
moparisthebestfrom https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning , and since everyone only looks at the examples... :D
moparisthebestRFC doesn't seem to suggest anything
ZashMaybe I should just shoot myself in the DNSSEC and see how long it takes to recover
ZashShould be on the order of hours
moparisthebestyea you generally don't have a DNS TTL of 2 months
ZashWorst case if someone is trying to mess with you would be a couple of weeks
moparisthebestbut both HPKP and DNSSEC/DANE should be the same in regard to breaking your website for however long your TTL says
adiaholichas joined
ZashRelatedly I did a CDS based key rollover and it was painless to the point of boring.
moparisthebestI've only rotated my DNSSEC keys once so far and I don't remember it being a problem but also don't remember details
ZashAs in, publish new keys and delegation records and the parent zone picks them up.
alacerhas left
Matthew (away)has left
uhoreghas left
Rixon 👁🗨has left
homebeachhas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
ZashDealing with certbot has been cumulatively more painful by now, and I don't even use it
matkorhas left
moparisthebestI only use acme.sh which by default doesn't change your key, so my key is published in a TLSA that never has to change
moparisthebestalso still using HPKP...
Zashdehydrated also has the amazing feature of _not_ replacing your keys
ZashFound out recently it can generate keys before using them, for rollover, which I'm in the middle of figuring out how to do.
adiaholichas left
adiaholichas joined
sabryhas joined
marchas left
marchas joined
emushas left
harry837374884has left
harry837374884has joined
emushas joined
moparisthebestfor hpkp I just generated encrypted backup keys years ago and published them, haven't switched to using them yet though
emushas left
millesimushas joined
emushas joined
adiaholichas left
marchas left
marchas joined
BASSGODhas left
moparisthebestStandards-wise I think I'm really leaning towards putting both discovery of connection methods (to replace srv) and key material (to replace Dane+posh) in host-meta, so we aren't adding yet another thing to look up, just parsing more things from the existing one...
sabryhas left
adiaholichas joined
moparisthebestIn my ideal world with dnssec everywhere we'd just use srv+dane instead, but that doesn't seem likely to happen soon? :'(
papatutuwawahas joined
Matthew (away)has left
uhoreghas left
Rixon 👁🗨has left
homebeachhas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
qwehas left
xnamedhas joined
APachhas joined
Menelhas joined
Dele Olajidehas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
adiaholichas left
adiaholichas joined
marchas left
marchas joined
harry837374884has left
matkorhas joined
me9has joined
Dele Olajidehas left
rubihas left
rubihas joined
adiaholichas left
fhtesthas joined
harry837374884has joined
jgarthas joined
Friendly Resident Cynichas joined
florettahas left
qwehas joined
djorzhas joined
me9has left
karoshihas left
florettahas joined
phrykhas joined
karoshihas joined
Steve Killehas left
Steve Killehas joined
djorzhas left
djorzhas joined
gooyahas left
Titihas left
gooyahas joined
djorzhas left
harry837374884has left
harry837374884has joined
julianhas left
fhtesthas left
djorzhas joined
florettahas left
wladmishas left
wladmishas joined
florettahas joined
gooyahas left
gooyahas joined
BASSGODhas joined
BASSGODhas left
BASSGODhas joined
wladmishas left
wladmishas joined
Steve Killehas left
Steve Killehas joined
qwehas left
guus.der.kinderenhas joined
gooyahas left
gooyahas joined
neshtaxmpphas left
neshtaxmpphas joined
fhtesthas joined
neshtaxmpphas left
neshtaxmpphas joined
fhtesthas left
fhtesthas joined
fhtesthas left
fhtesthas joined
Titihas joined
gooyahas left
gooyahas joined
rafasaurushas left
gooyahas left
gooyahas joined
restive_monkhas left
rafasaurushas joined
Dele Olajidehas joined
Dele Olajidehas left
adiaholichas joined
robertooohas left
adiaholichas left
robertooohas joined
robertooohas left
robertooohas joined
Yagizahas left
qwehas joined
argentumhas left
restive_monkhas joined
restive_monkhas left
jgarthas left
jgarthas joined
wladmishas left
wladmishas joined
xnamedhas left
ti_gj06has left
ti_gj06has joined
adiaholichas joined
papatutuwawahas left
wladmishas left
wladmishas joined
karoshihas left
pasdesushihas left
adiaholichas left
Mikaelahas left
wladmishas left
wladmishas joined
xnamedhas joined
neshtaxmpphas left
neshtaxmpphas joined
ti_gj06has left
pasdesushihas joined
gooyahas left
gooyahas joined
karoshihas joined
gooyahas left
gooyahas joined
Andrzejhas left
Andrzejhas joined
ponymontanahas joined
ponymontanahas left
guus.der.kinderenDoes anyone have experience with moving a server-implementation from stringprep to precis?
guus.der.kinderensome quick tests on our server show that out of 241277, 68 seem to have issues when trying to compare them to all others.
msavoritiashas left
Titihas left
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Titihas joined
Andrzejhas left
me9has joined
karoshihas left
karoshihas joined
adiaholichas joined
Andrzejhas joined
florettahas left
andrey.ghas joined
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
wladmishas left
wladmishas joined
Dele Olajidehas joined
andrey.ghas left
adiaholichas left
Dele Olajidehas left
Dele Olajidehas joined
Vaulorhas left
Dele Olajidehas left
beanhas left
fhtesthas left
Tobiashas left
Sevehas left
Sevehas joined
Vaulorhas joined
florettahas joined
Menelhas left
ti_gj06has joined
Andrzejhas left
Andrzejhas joined
me9has left
guus.der.kinderen(I ment to inject 'usernames' in there somewhere)
reimarhas left
marchas left
millesimushas left
marchas joined
marc0shas left
marc0shas joined
marchas left
ti_gj06has left
marchas joined
florettahas left
moparisthebestI thought the consensus was that couldn't be done