pep.That is really meh. Who was talking about trying to reach email people again
SaltyBoneshas joined
SaltyBoneshas left
pep.See how they cope with that.
winfriedno, safe harbour is part of the EU-US adequacy decision: "if you keep to privacy shield, it s adequate"
Dave Cridlandhas left
jubalhhas joined
pep."Hey users, you can't reach half of the planet from now on"
SaltyBoneshas joined
pep.winfried, how is this privacy shield defined?
Timhas joined
Syndacehas left
Syndacehas joined
pep.hmm, what about 49.1a?
Ge0rGAFAIU third countries are also covered by user consent
pep.yes just what I pointed out I think
winfriedprivacy shield is a (before GDPR) construct to legalise EU-US transfer, saying: when keeping to privacy shield, then the protection in the US is adequate and permitted
alexishas left
jonaswI’m trying to find a clue about it in the google privacy policy atm
winfried(And Schrems finely argued it was not adequate becease the NSA was left out it)
alexishas joined
winfriedSo now al companies leave adequacy as ground and use standard clauses
pep.I'd say article 49 applies quite a lot
jonaswso, there’s nothing in that
jonasw(that = google privacy policy)
jonaswwith respect to federation
jonaswI begin to suspect that the following applies:
sezuanhas left
winfriedjonasw: you just found an interesting legal gap at google ;-)
Ge0rGjonasw: sue them!
ThibGhas joined
jonasw1. the user has a clear intent to share a message with a recipient when they send a message.
2. it is up to the recipient how they handle the data. this includes whether they consent to it being stored on their server and for how long
pep.winfried, they have more laywers than you will ever have
jonaswnow how that works in the light of germany’s whatsapp decision, I don’t know.
Timhas joined
moparisthebesthas joined
Ge0rGjonasw: I tend to agree with you here, however... by sending a message you only show implicit consent in that the message is to be delivered to the recepient, not that it shall be analyzed to create a profile of your sex life.
winfriedpep.: yes, but for example when analysing Microsofts new terms, I found over a douzen issues that were violating EU law
jonaswGe0rG, that’s true, but if the receiving party consented to that?
jonaswthat’s a matter between you and the receiving party then, isn’t it?
jonaswI mean the receiving party could also simply upload all your messages manually to some service which does that to gain some moneyz.
Ge0rGjonasw: yes.
jonaswso nothing which concerns server operators?
pep.interesting
moparisthebesthas joined
Ge0rGjonasw: the receiving party must gain your consent to process your data.
jonaswbut that’s #notourdepartment?
Ge0rGyes
pep.Ge0rG, by subscribing?
jonaswso we can simply not give a fuck?
pep.Or joining a MUC, or ..
jonaswI don’t think that subscription is consent for any level of advanced processing.
winfried49.1b may be very applicable here
jonaswnot for art 9.1 type processing at least
Ge0rGjonasw: maybe. Maybe we need to explicitly tell the user that their messages might leave the EU
pep.winfried, if 49.1b is not enough, there's still 49.1a
pep.Ge0rG, 49.1a then
pep.explicit consent
jonaswGe0rG, mmm, I feel that this might be a reasonable assumption.
jonaswlike, if you send a message overseas, it’ll be overseas, period.
alexishas left
jonaswhowever, it’s unclear that you might send a message overseas when I send a message to somebody who is in e.g. sweden but has an account at $USProvider
pep.I fear users do not know if it will be overseas, but we can just state the possibility in anycase
Ge0rGI'm pretty sure we can argue that 49.1b applies here: you have a service contract with the XMPP server, and if you want your messages to be sent overseas, the server will happily do so
alexishas joined
Ge0rGjonasw: $USProvider is subject to GDPR then.
winfriedpep.: my reading is you need one of 49.1a-49.1g
pep.winfried, yes
jonaswI think c applies
pep.if 45 and 46 don't apply
Ge0rGjonasw: I don't thing 49.1c applies here
Andrew Nenakhovhas left
pep.jonasw, as in, contract between server operators ?
danielhas joined
winfried49.1c needs a contract between server operators and it needs to be in the interest of the user. Mainly the first one is problematic, the second one may be
Ge0rGI think that 1b is better applicable here.
Andrew Nenakhovhas joined
pep.Well we don't have to settle on one, unless it's 1a
pep.If both apply, great
rtq3has left
rtq3has joined
winfried49.1b says (more or less) and analouge to 6.1b: when it is needed to perform the request of the user
Ge0rGYup.
pep.yes
winfriedand that one is quite clear: we federate and transfer on request of the user
sezuanhas left
jonaswGe0rG, oh indeed I misread
pep.Indeed, I only have that s2s connection if a user requests it
winfried49.1a feels a bit like a minefield to me
Ge0rGSo I'd argue that transfer of content is covered by 49.1b because the user wanted the content to be sent to wherever, and meta-data is covered because the user wanted to subscribe or somesuch.
winfriedGe0rG: +1
pep.Seems good to me
Ge0rGIt might be a good tech TODO to have that written in the data policy.
pep.fires vim
lnjhas joined
Ge0rGpeople that you approve as contacts will be able to see your online status.
jonaswGe0rG, mmm, with subcsription I’d argue that some things aren’t obvious.
winfriedis listening
jonaswah, that’s what you meant
jonaswmakes sense
pep.jonasw, I think we ought to make them obvious in the policies
Ge0rGjonasw: let's make a list
jonaswGe0rG, ack
jonasw1. vcard avatar is always publicly visible
jonasw2. pep avatar and other pep things are most likely visible to your contacts. what things are there, besides avatars?
Ge0rGjonasw: vcard avatar is public data. maybe good to have a separate category for that
jonasw3. last online timestamp, status message, online status, list of online devices
Alexhas joined
jonaswlist of online devices also means things like software version btw
jonaswbecause if you know the resource, you can IQ
Ge0rGjonasw: I think that #2 is actually well covered implicitly. If you "play a tune", you want that to be shared with your friends
jonaswpossibly
danielhas left
jonaswit’s the clients job to make that explicit at least
Ge0rGI don't want to open _that_ can of worms
jonaswyupp
jonaswthat’s fine
jonaswlet’s focus on what must be done on the protocol/federation/server level.
Ge0rGso we need two lists: things shared with everyone; things shared with contacts
alexishas left
winfriedGe0rG: yes
Ge0rGthe latter might contain surprises to the user.
Ge0rGwith everyone = with everyone who knows your JID
pep.And things not shared, as in credentials etc., even if obvious
alexishas joined
Martinhas left
winfriedGe0rG: you can assume a JID to be publicaly known
jubalhhas left
pep.Ge0rG, maybe define "everyone who knows you JID" a bit more? contacts, non-anon MUC owners
Ge0rGwinfried: can I?
pep.other server operators
Tobiashas joined
pep.winfried, I don't think so
Ge0rG"contacts, chatrooms and their server operators"
winfrieddon't know if that discussion is *very* relevant here/now but in practice most people publish their JID, so they can be contacted...
Ge0rGwinfried: if you publish your JID, your JID is obviously public
Ge0rGwinfried: but what if not
lnjhas left
pep.I'm going to go soon-ish, starting to get hungry
pep.This list falls under things to be transparent about in the privacy policy then
winfriedI will try if I can get some opinions on sensitive data in some lawyer groups I participate in
jonaswI’m sure it’s sensitive data. I’d just like to have clarification on if simple store-and-forward (and no analysis) brings us into 9.1 realm
winfriedjonasw: exactly
jonaswneat
jonaswso, date of next?
jonaswmy constraints shifted and I’m unavailable thursday this week
pep.not tomorrow if possible
pep.Fri noon?
jonaswfriday would wfm, something like 10:30 CEST -- 11:30 CEST e.g.
Ge0rGso friday?
pep.I'm not available in the morning
jonaswis 10:30 still morning at yours?
pep.yes
jonaswI see
Ge0rGI'm blocked after 1300CEST
danielhas joined
pep.before 12 is morning :P
pep.hmm
jonaswmmm, I can’t promise 12:00CEST
Ge0rGpep.: set up an alarm :P
alexishas joined
pep.Ge0rG, I have paid job to do
pep.In between :p
Ge0rGyeah, right :P
winfriedFriday I am available between 12:00 and 13:30 CEST
pep.I can do 9:30 here, 8:30UTC
alexishas left
alexishas joined
pep.if it doesn't go more than an hour
Ge0rGjonasw: take your laptop to the lunch break? ;)
Ge0rGit never went more than an hour!
jonaswGe0rG, lunch break people won’t approach
jonasw*approve
jonaswwtf is wrong with me
pep.ok so 10:30CEST
pep.In the end
jonasw10:30 CEST on friday, ACK
Ge0rGwinfried> Friday I am available between 12:00 and 13:30 CEST
Dave Cridlandhas left
jonaswoh
jonaswwelp
pep.hmm
jonaswotherwise, next week same time as today would work for me too
winfriedOK, when doing some magic with my schedule, I can be reading from 10:30 but only be (really) active from appr. 11:00
pep.Sure, Mon, Tue workforme
Ge0rGwe need to get this settled soon.
pep.Fri I'm not here from 11:45 CEST to ~12:45 CEST
jonaswI blocked friday 10:30 CEST, and I blocked Tue 12:30 CEST, I don’t care which you chose :)
pep.Tue 12:13 CEST is fine by me
winfriedTue wfm (more or less)
pep.What works better?
winfriedTue
pep.Tue when?
winfriedafter 9:30 CEST
pep.I can do 10:30 CEST again on Tue, or anytime after that
jonaswGe0rG, 12:30 CEST on Tue?
Ge0rGcan do
jonaswthen it’s settled
winfriedTuesday 12:30 CEST
winfriedbangs the gavel
pep.:)
mimi89999has joined
pep.what do you call morning btw? if it's not before noon
alexishas left
jonaswhmmm, in german there’s "vormittag", which awkwardly translates to pre-noon.
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
pep.Ok, I know in quebec they also have this weird notion of early morning and before noon, but in france I've never heard that
pep.(french quebec)
jonaswit’s not particularly weird, considering we have the same for after noon
pep.Sure. Though in usual my mornings are pretty short anyway, so just having one word is fine by me :P
winfriedpep.: lol
Ge0rGmorning is the time between your first coffee and being awake.
winfriedwhat's in a word!
pep.Ge0rG, can that also include noon?
HolgerGe0rG: So morning == afternoon?
jonasweven more weird are the swedes, where "middag" is both dinner and noon. eftermiddag is only afternoon, but not after dinner.
pep.:D
winfriedGe0rG: that is never in my case, I don't drink coffee and I am never awake :-P
tahas left
Zash"förmiddag"
Ge0rGwinfried: then you have an eternal morning?
pep.I'll try to send the minutes today. And update the wiki after that
Zashthe morning that never ends?
pep.out for lunch
jonaswZash, do you have a highlight on "swede"?
winfriedGe0rG: welcome in my life ;-)
jubalhhas joined
alexishas left
MattJjonasw, he has a highlight on "coffee"
jonaswMattJ, that makes sense
alexishas joined
alexishas left
Ge0rGA highlight on "highlight"
alexishas joined
alexishas left
alexishas joined
valohas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
alexishas left
alexishas joined
ibikkhas left
ibikkhas joined
alexishas left
alexishas joined
Timhas joined
tim@boese-ban.dehas joined
jonaswis dwd saying "do a PR, because a vote without PR isn’t really useful at all"?
jonaswif so, I find that hard to get from that email :)
MattJWell, he's not instructing, but... yes
alexishas left
alexishas joined
MattJVoting on "X is a nice idea" and "PR X is good to merge" are different things. But I imagine Ge0rG would rather not work on a PR unless the council indicates it would be in favour of the idea of removing GC1
Ge0rGWhat MattJ said.
Ge0rGI can only imagine that Dave assumes I'm not sufficiently familiar with the Council process.
jonaswor maybe is confused by your attempts to vote to abolish pidgin ;-)
KevI don't *think* Dave's mail says that.
KevI *think* he's just observing that the vote has no practical effect, rather that that it's a bad idea to have the vote.
Ge0rGThe practical effect will be that I'll get green lights on preparing a PR, and maybe even some Feedback From The Elders.
KevGe0rG: That's not an effect of the vote, though, that's an effect of us discussing it.
ThibGhas joined
Ge0rGObviously, a Council member could decide to lure me by +1ing the general principle vote and then blocking any follow-up PR, but I don't hope this is going to happen.
KevI think the vote's a sensible thing to do, as a forcing function for discussion, but it doesn't achive anything that the discussion without out a vote wouldn't.
Ge0rGKev: there is actually one outcome I'm looking for: Council consensus on removal of GC1.
Ge0rGKev: if we don't manage to achieve that consensus, I'm not going to prepare a PR.
KevI think that's very sensible.
Zashhas left
Ge0rGWhich probably wasn't crystal clear from my e-mail.
KevAnd I think a vote as a forcing function on the discussion is sensible, too.
efrithas joined
KevJust that it's not really *necessary*.
Ge0rGRight.
marmistrzhas left
Ge0rGI'm painfully aware that if the vote is accepted, we'll have a second vote on the subject matter of the PR.
Ge0rGEven my mail to standards@ can be used to discuss the motion in the wider community.
danielhas left
alexishas left
KevI'm against it on the basis of having been reworking M-Link's MUC implementation recently and I implemented and tested GC1 joins :p
Kev(No, I'm not really)
Ge0rGKev: you have nobody but yourself to blame. I've clearly stated my goal of burning GC1 half a year ago
alexishas joined
alexishas left
alexishas joined
KevI'm not opposed in principle, but I do think we should have a story for how to address the 'just fix out of sync' that GC1 currently works for.
Ge0rGKev: "works"
ZashKev: It does the opposite of fixing anything.
KevIt's not good, but it *does* work around some things at the moment.
Keve.g. if you've desynched then at least a presence broadcast means you start getting messages again.
blablahas left
ZashKev: You'll still be desynced
KevWe should describe how to detect and resolve those cases at the same time as getting rid of GC1.
ZashAs in, your view of the participant list may be outdated.
KevZash: You will. You'll also be receiving messages.
Ge0rGI think I made multiple proposals back in October.
Martinhas joined
Ge0rGI could make an even more revolutionary one: let the MUC respond to self-pings by a participant.
ZashKev: True. Sending a full join bundle would help in that case.
Ge0rGZash: not quite
ZashGe0rG: Assuming clients understand "ok, forget everything, here's the current state", which might need adding
Ge0rGZash: because you'll end up with zombie users in your participant list
Ge0rGZash: yes. Assuming there is some kind of marker in the stream telling the client when to forget everything from before
Ge0rGwhich there isn't in the normal join bundle
moparisthebesthas left
ZashCorrect. So Kev says we should address that.
jerehas joined
ZashReturning an error and making the client rejoin does have the same end result tho, at the cost of a roundtrip
Ge0rGZash: except that most clients suck at rejoining.
alexishas left
alexishas joined
Ge0rGZash: somebody could implement a server-side MUC bouncer that hides all of this from the client.
ZashGe0rG: *ahem* mod_minimix?
Ge0rGZash: I don't appreciate that name very much, but yes.
ZashNaming things is hard
Ge0rGZash: also I had a brief look at the source code and decided not to load it on yax.im
ZashGe0rG: Sane choice.
Dave Cridlandhas left
jonaswmod_minix -- run a minix inside lua and own all your traffic
jonaswmod_mimimix -- complain about all attempts to join MIXes in the logs
Ge0rGmod_mixtape - play low-quality music whenever somebody joins a mix
Anuhas joined
ZashHold on, how do you trick a MUC into subscribing to your presence?
Ge0rGOh. Hm.
Ge0rGRight, adding a MUC to your roster doesn't imply much.
Ge0rGI wonder what happens if you send a subscription request to a MUC
alexishas left
alexishas joined
Guushas left
andyhas joined
lovetoxhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Valerianhas left
Dave Cridlandhas left
la|r|mahas joined
la|r|mahas joined
alexishas left
Valerianhas joined
alexishas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
KevMy concern is that things are bad with desyncs, and we'll make them worse by just stopping doing gc1.
KevAnd on a Draft XEP that's not on.
Ge0rGKev: we'll just make clear how bad it actually is.
danielhas left
alexishas left
jonaswKev, silently losing messages (what we currently have) is worse than explicitly dropping out of a MUC.
Ge0rGKev: but I'm open to suggestions how to transition into the new world of awesome MUC without causing regressions
Kevjonasw: And that's not what's on the table.
Marandare-read the gdpr thing
jonaswKev, it’s not?
Kevjonasw: What's on the table is silently losing some messages vs silently losing more messages.
jonaswKev, no, you don’t *silently* lose more mesasges
jonaswthe user and client are aware that they’re losing messages, which isn’t the case with a silent pseudo-resync which happens on accidental GC1.0
lnjhas joined
Ge0rGare aware that they *were* losing messages,
jonaswGe0rG, true.
Kevjonasw: But how many existing clients are dealing with whatever behaviour we're moving towards?
alexishas joined
MarandaSo in the end "user must explicitly give consent to treatment of his/her data by 3rd parties (receiving) when using s2s" is legally covering glad we got to that at least.
jonaswKev, if the MUC replies with a "kicked" status code, every single one I think.
Kevjonasw: I'm not opposed to fixings, but we do have to be sure we're actually fixing them.
Ge0rGjonasw: I really dislike "kicked" as opposed to a presence-error
Kevjonasw: Great, so the user isn't getting messages and eventually they might wonder why that tab has gone quiet and look why and see they left 3 days ago.
Ge0rGjonasw: because a sane client won't auto-rejoin after being kicked
MarandaoO(and "who would have told" ™️)
jonaswGe0rG, kicked + 333 maybe?
Ge0rGjonasw: that's not backward compatible to clients not parsing 333.
jonaswGe0rG, I’m not sure if clients handle type="error"
Ge0rGjonasw: I'm speaking of "sane" clients.
jonaswKev, dunno, I’d *expect* clients to tell me that I got kicked out of a MUC.
j.rhas left
jonaswGe0rG, me too
j.rhas joined
Anuso are we discussing MUC or what the new lighter MUC will be
jonaswGe0rG, have you made a survey how many handle type="error"?
jonaswAnu, MUC
MarandaAnu, uncertain.
Ge0rGKev: yes. It's better to see after three days that you got kicked than to lose three days worth of discussion and then silently rejoin
Anuah
Alexhas left
KevGe0rG: except probably you don't lose 3 days of messages under gc1, because you will have silently kinda rejoined.
Ge0rGAnu: I've stirred some controversy on the standards@ ML
KevI'm not saying gc1 is a good thing.
KevOr arguing that it should stay.
Ge0rGKev: maybe you only rejoined after two days.
KevI'm just saying that it's not clear that we yet have a story for what happens next.
MarandaAnd why auto-rejoining is insane?
Maranda🤔
Ge0rGMaranda: it isn't, unless you were just kicked
AnuGroup chat (as people expect it) is such a solved problem. In my honest opinion, we should probably spit up the IRC clone from the kind of group chat people use today (which is more of a distribution list)
Ge0rGAnu: yes, but then everybody wanted their favorite feature in and we ended up with MIX
KevGe0rG: I think that's right, actually. We do need to get the MAM resync in there.
Maranda:O
jonaswyeah, MIX is in the state of "silent message loss", but with better recovery times than MUC
Ge0rGjonasw: recovery times? I don't see no recovery times in MIX
jonaswGe0rG, in theory, each message stanza would trigger an s2sout attempt at the MIX side of things.
Ge0rGKev: so I assume your statement should read "MIX is MUC with additional issues." :P
jonaswwhich is *probably* better than what happens with MUC-GC1.0-pseudo-resync which only happens when a client happens to update its presence.
jonaswMIX fixes the resource part abuse.
KevAnd the long-term join.
Marandathinks currently MIX is in the "it'll cause a core meltdown", but he's vaguely biased.
KevAnd the multi-client.
Anuhas left
ludohas left
Martinhas left
ludohas joined
jonasweverybody loves core dumps
MarandaStick a state somewhere in that last sentence
Ge0rGjonasw: I'm not sure this is a real problem. And if it is, I'm not sure that abusing the localpart of the MIX JID to contain two fields is a good solution.
Ge0rGKev: we can solve multi-client long-term join in MUC without touching a single line of XEP.
MarandaAgreed
KevI'm quite sure that's not true.
Ge0rGAll we need is a bouncer on the user's account that syncs with 0048.
jonaswGe0rG, it doesn’t shake the concept of "same bare JID == same identity", which is good enough for me I think
Ge0rGOr 0402, or whatever.
KevAs long as we have full-JID sharing, iq is going to be broken.
jonaswyeah
Ge0rGjonasw: except in MIX you have a 1:N relationship between identities and JIDs over different MIXes
Martinhas joined
MarandaAlthough I'm somehow also sure somehow "bncs" will also be a cause of nuclear meltdowns
jonaswGe0rG, I’m not sure that matters much.
SamWhitedhas left
Guushas left
Ge0rGKev: what are the IQ use cases in MUC?
KevAny time you want to do anything that involves an iq.
jonaswGe0rG, initiating a call with an occupant (not the whole MUC)
KevSo the same as non-MUC.
danielhas left
Ge0rGKev: and self-references are self-references.
Anuhas joined
Ge0rGThe only IQs I'm actively using are (self)ping and version, and I just made a proposal to fix #1 and I can live with the ambiguity of #2
Marandaeyes that "Thesis Survey" in jdev@
Anudesync = netsplit ?
Ge0rGAnu: kind of.
Ge0rGAnu: https://mail.jabber.org/pipermail/standards/2017-October/033501.html has an in-depth explanation
MarandaGe0rG vcard:temp also
jonaswMaranda, vcard:temp is on the account, not on the occupant✎
jonaswMaranda, vcard:temp is on the account, not on the resource ✏
MarandaAnd time
Dave Cridlandhas left
jonaswso that’s about the one case where it doesn’t matter in MUC :)
AnuWe should all just use EF net and be happy
MarandaWhat? Hmm is there a difference jonasw?
Ge0rGMaranda: yes, in MUC you query the full JID for the vcard, and it gets routed by the MUC to the account of the participant
Kevjonasw: No, actually, vcard:temp is another example of iq being broken.
KevBecause it should go to the full JID of the occupant, not to their bare JID.
jonaswKev, wha?
jonaswITYM the other way round?
KevSo all* MUC implementations have some special casing to detect a vcard and send it to the wrong place (bare JID) instead of the normal routing rules [*probably].
Ge0rGKev: so there is a viable workaround for that.
jonaswah, "should" in the sense of "the normal routing rules"
jonaswGe0rG, so we wanna staple further workarounds onto MUC for every IQ which might ever need to go to the bare JID?
Marandais confused with occupant != account muc wise
MarandaWaiting for cell to return ™️
Ge0rGjonasw: I'm sure the incremental overhead is minuscule.
jonaswGe0rG, but the adoption delay?
jonaswand the difficulties for new implementers.
jonaswand of course, the client code which needs to special-case requesting stuff from MUC occupants.
SamWhitedhas left
Ge0rGjonasw: write it down in 0045.
danielhas left
jonaswyou mean like the vcard:temp hack is written down?
Ge0rGjonasw: the special-casing in my client is just in two places :>
Ge0rGjonasw: dunno. I'm not a server author. I'm busy enough keeping 0045 usable for client devs.
MarandaWell iq routing has always been hassle in muc, e.g. who do you send to on ping, version, time etc
Ge0rGa.k.a. not my department.
MarandaIn case of shared nick
Maranda😎
Ge0rGMaranda: I suggest "highest priority"
KevMaranda: Yes, that's one of the things that's fundamentally broken with MUC addressing.
Ge0rGno, "most available"
lnjhas joined
jonaswI suggest least mobile
Alexhas joined
MarandaLeast mobile 🤔😆
@Alacerhas left
@Alacerhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guushas left
Guushas left
Guushas left
marmistrzhas joined
MarandaAnd no hacks aren't written down e.g. Multi resource nicks
j.rhas left
Ge0rGMaranda: PR the XEP!
andyhas left
ThibGhas joined
Zashhas left
SamWhitedhas left
Dave Cridlandhas left
Anuhas left
rtq3has left
SamWhitedhas left
rtq3has joined
MarandaGe0rG I would use someone more literate than myself english wise
Maranda😜
Ge0rGMaranda: just don't plaster it with Emoji :P
alexishas joined
alexishas left
alexishas joined
alexishas left
alexishas joined
jerehas joined
jerehas joined
Holger#18.1.2 Ghost Users 👻
Holger#5 Roles, Affiliations, and Privileges 😱
marmistrzhas joined
waqashas joined
Guushas left
alexishas left
alexishas joined
marmistrzhas joined
MarandaMobile Chrome even hangs browsing xeps
Maranda🤔
Ge0rGI was going to suggest status code 666 for the Ghost Rider.
alexishas left
Ge0rGOr maybe the GOST Rider. zinid and Andrew would appreciate that.
Maranda666 which in reality is 999
alexishas joined
Valerianhas left
Valerianhas joined
Dave Cridlandhas left
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Guushas left
Valerianhas left
SamWhitedhas left
edhelaspropose to ping Ge0rG to check the state of all the MUCs
UsLhas joined
alexishas left
Ge0rGedhelas: great idea. And then I quit XMPP and everybody's clients go offline
alexishas joined
danielhas left
edhelasthen I'm adding "Ge0rG MUST stay online" to the XEP
jjrhhas left
Ge0rGedhelas: I'm not sure you need to write that into the XEP, it might suffice to get a Council vote.
Ge0rGI'll request XSF funding for a multi-homed redundant-hardware HA cluster to run my poezio.
Ge0rGOh, wait. poezio needs restarts as well. I will request funding to develop a new client written in Erlang.
jonaswMaranda, regarding english literacy, that’s the editors job when in doubt
Maranda😲
Ge0rGjonasw: I didn't want to say that, knowing that the editors are pretty busy
jonaswGe0rG, that’s no reason not to say the truth :)
jubalhhas joined
UsLhas joined
Ge0rGjonasw: while you are there... I have some pending PRs :D
jonaswGe0rG, I know that
jonaswI have a pending PR mysefl
jonaswbut unfortunately, what you were saying is also true ("the editors are pretty busy")