DanielWell technically it's probably incitement. Which is illegal. But INAL and nobody is going to sue over that.
lovetoxhas left
Marandahas left
winfriedhas left
winfriedhas joined
adiaholic_has left
adiaholic_has joined
Marandahas joined
Mikaelahas joined
adiaholic_has left
adiaholic_has joined
jcbrandhas joined
sonnyhas left
karoshihas joined
sonnyhas joined
stpeterhas joined
stpeterhas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
sonnyhas left
sonnyhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
sonnyhas left
sonnyhas joined
marchas joined
eevvoorhas joined
eevvoorhas left
eevvoorhas joined
lorddavidiiihas left
lskdjfhas joined
sonnyhas left
sonnyhas joined
eevvoorhas left
eevvoorhas joined
goffihas joined
amuza@riseup.nethas joined
Lancehas left
lorddavidiiihas joined
marchas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
adiaholic_has left
adiaholic_has joined
adiaholic_has left
adiaholic_has joined
sonnyhas left
winfriedhas left
winfriedhas joined
Steve Killehas left
sonnyhas joined
Steve Killehas joined
adiaholic_has left
adiaholic_has joined
neshtaxmpphas left
sonnyhas left
sonnyhas joined
sonnyhas left
neshtaxmpphas joined
sonnyhas joined
sonnyhas left
eevvoorhas left
eevvoorhas joined
sonnyhas joined
neshtaxmpphas left
Lancehas joined
sonnyhas left
sonnyhas joined
alameyohas left
Lancehas left
Nekithas left
debaclehas joined
sonnyhas left
sonnyhas joined
Nekithas joined
emushas joined
dwdlovetox, You're not allowed to send data to the FBI; it would be illegal under the GDPR.
sonnyhas left
dwdmoparisthebest, But, a GDPR Subject Access Request over XMPP would be legit and require a response within a fixed time period of a month (and without "undue delay").
dwdmoparisthebest, (This case isn't a DSAR, of course, as the FBI is not a Data Subject here)/
stpeterhas joined
stpeterhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
marchas joined
sonnyhas joined
eevvoorhas left
sonnyhas left
lovetoxhas joined
sonnyhas joined
sonnyhas left
sonnyhas joined
alexishas left
Dele Olajidehas joined
alexishas joined
sonnyhas left
sonnyhas joined
debaclehas left
sonnyhas left
sonnyhas joined
lovetoxhas left
Nano4BeingYouhas left
sonnyhas left
sonnyhas joined
sonnyhas left
!XSF_Martinhas left
!XSF_Martinhas joined
sonnyhas joined
j.rhas joined
Lancehas joined
adiaholic_has left
adiaholic_has joined
sonnyhas left
j.rhas left
Half-Shothas left
uhoreghas left
Rixon 👁🗨has left
uhoreghas joined
Half-Shothas joined
Rixon 👁🗨has joined
Nekithas left
lovetoxhas joined
adiaholic_has left
adiaholic_has joined
Lancehas left
dwdhas left
krauqhas left
alexishas left
debaclehas joined
krauqhas joined
winfriedhas left
winfriedhas joined
stpeterhas joined
stpeterhas left
sonnyhas joined
larmahas left
larmahas joined
adiaholic_has left
adiaholic_has joined
sonnyhas left
sonnyhas joined
eevvoorhas joined
alexishas joined
winfriedhas left
winfriedhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
emushas left
emushas joined
alexishas left
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
alexishas joined
sonnyhas left
amuza@riseup.nethas left
LNJhas joined
LNJhas left
alexishas left
LNJhas joined
Marandahas left
Marandahas joined
sonnyhas joined
emushas left
emushas joined
AlexMemberbot is still online for our member meeting today. If you are a XSF member and have not voted yet then please do so. Thanks.
alexishas joined
jonas’Alex, Thanks! I won’t be able to attend in-person, but I already voted :)
emushas left
emushas joined
MattJJust voted :)
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
alexishas left
Lancehas joined
florettahas left
alexishas joined
Lancehas left
alexishas left
alexishas joined
stpeterhas joined
stpeterhas left
alexishas left
alexishas joined
lovetoxhas left
lovetoxhas joined
neshtaxmpphas joined
lovetoxhas left
murabitohas left
ikeameatballshas joined
ikeameatballshas left
neshtaxmpphas left
adiaholic_has left
adiaholic_has joined
neshtaxmpphas joined
mukt2has joined
neshtaxmpphas left
lovetoxhas joined
neshtaxmpphas joined
Mikaelahas left
neshtaxmpphas left
neshtaxmpphas joined
Nano4BeingYouhas joined
murabitohas joined
florettahas joined
Mikaelahas joined
Lancehas joined
bearhas joined
alameyohas joined
Lancehas left
alexishas left
lovetoxhas left
lovetoxhas joined
lovetoxhas left
lovetoxhas joined
DebXWoodyhas left
mukt2has left
stpeterhas joined
stpeterhas left
Shellhas joined
lovetoxhas left
lovetoxhas joined
sonnyhas left
sonnyhas joined
mimi89999has left
Nano4BeingYouhas left
mimi89999has joined
Wojtekhas joined
etabtw, I've been thinking about ways to solve s2s connection issues (and push notifications) with MUC/XEP-0045 in ways that are mostly invisible to the clients participating in the MUC. I wrote up a 1,900 word very rough form of a XEP, and will probably look at converting that into a "proper" ProtoXEP soon :)
etathe basic idea is to have the user's server perform MUC Self-Ping on the users' behalf and intelligently handle rejoining & history replay for the client, removing the need for the client to support such logic
etaMUC servers must implement Unique and Stable Stanza IDs for the catchup to work, and are strongly advised to implement MAM and the optimization parts of MUC Self-Ping (but these aren't hard requirements)
jonas’eta, that doesn’t solve all of the issues
jonas’unfortunately
moparisthebesteta: is that prosody mod_minimix ?
jonas’but it improves the situation
etajonas’, do tell
etawhat issues remain?
etamoparisthebest, no, it's something different
sonnyhas left
jonas’eta, ah, well, if you force servers to do MAM catchup and replay on behalf of their users, that’s good
jonas’otherwise this won’t quite work
Zashjonas’, wanna write down all the issues on the wiki or such?
jonas’Zash, -EBUSY
Zash-WSADFACE
etajonas’, so how I've spec'd it is that if your client conforms to this new XEP it just gets a "room oops happened, please do MAM resync" message and handles MAM itself
jonas’I just came back from the police department (which was already closed) and that kind of stole more of my time than I had budgeted for
etaif your client doesn't advertise support, the server will do MAM for you and forward the messages
jonas’eta, ah, that’s not at all "invisible to clients" then
jonas’and not much of an improvement over self-ping, is it?
jonas’why not always let the server do MAM?
etajonas’, because paging
jonas’I don’t folloo
jonas’I don’t follow
etalet's say you're disconnected for an extended period and miss out on like 1000 lines of history
jonas’yeah
etanow the server will perform MAM to filter through that to see if any of those lines contain your nickname (for push purposes)
etabut it won't want to buffer all 1000 and send them to you, because that drains the server's resources unnecessarily
jonas’but if a client doesn’t support it, the server still has to do it, right?
etayeah, so there's a limit
jonas’I don’t like that
jonas’don’t hide issues if you can’t hide them completely
ZashWill perform MAM ... when?
ZashPeriodically?
jonas’Zash, after MUC self-ping errored
etaZash, upon reconnect
ZashPolling? Hmmmm, not sure if like
etaZash, polling is required
undefinedhas joined
lovetoxhas left
etacopy-paste
jonas’ok, well
eta"Fundamentally, due to the way s2s links work (i.e. they get suspended on lack of activity), we'll always need to perform some kind of polling to make sure we're still in a MUC. Doing things like the server proactively saying it's back and clients should rejoin is *good*, but it'll never cover all cases due to the nature of networking. Therefore, it's probably a good idea to have a user-configurable polling interval that defaults to something like "10 minutes since last activity observed to/from the MUC" that people can tweak if they really care about knowing about disruption earlier."
jonas’I shall write stuff down later
etaZash, also this is a strict improvement upon the status quo, right
jonas’no
etaclients currently have to poll anyways
etait's better if the server does it once than having all connected resources do it
jonas’if you hide message loss (the > 1000 messages situation), that’s not an improvement
etajonas’, it's not hidden
jonas’how is it not hidden?
etajonas’, you either support the XEP, in which case you get an explicit "do a MAM resync" notification, or you don't, in which case you just get kicked
jonas’if the client does not advertise support, servers will simply not send all of the history, but fake as if the client had been in the room all the time.
etano, they won't
etait kicks you in that case
jonas’hue?
undefinedhas left
jonas’what about the MAM stuff you said earlier then?
etaso it tries to do a catchup
jonas’ah, and if that’s too much, you get kicked
jonas’makes sense
etayeah
etaand then you just do whatever retry logic you currently do
sonnyhas joined
eta(except it'll tell you that it kicked you for this reason, so you can instarejoin knowing that you're actually still in the MUC and just need to do MAM)
Zashcurrent retry logic: none
MattJCount me as interested, I've long thought we need to fix this on the server side, but haven't been able to put in the time to spec anything up
etaI mean I'll write this up into a proper protoXEP at some point soon once I figure out how to do that
etathe current doc is somewhat incoherent
MattJStep 1: obtaint markdown-to-xep
MattJStep 1: obtain markdown-to-xep
etaif there are no glaring issues with it, I'll probably forge ahead with trying to write prosody modules
etaoh yeah, the other thing I forgot to mention is
jonas’eta, ok, that makes much more sense.
etathis XEP has bookmarks2 as a hard dependency
MattJ:)
jonas’eta, I’ll be happy to help you through the XEP process -- let me know if you need any technical help in getting this in the right format
jonas’speaking of right format: MattJ, do you have it on your todo list to clean up the new mam-forked XEPs?
etabasically the flow is without a bookmarks2 entry for a room, you don't get any server fanciness
MattJjonas’, what needs cleanup specifically?
etaso to engage the fanciness, you join normally, then add a bookmarks2 entry
jonas’MattJ, they are lacking some RECOMMENDED/REQUIRED sections IIRC
eta(at which point the fun state machine specified in the XEP kicks into action and joins another resource that the server controls)
MattJOk, that wasn't on my todo but I can look into it
MattJProbably not for a couple of weeks though
jonas’MattJ, I see, thanks nontheless
jonas’nothing too urgent anyways
etaonce the fun durable mode is engaged, you never get kicked out of the XEP unless (a) someone actually /kick-ed you or (b) the server gave up retrying to get you back in (usually after like a day)
etaonce the fun durable mode is engaged, you never get kicked out of the MUC unless (a) someone actually /kick-ed you or (b) the server gave up retrying to get you back in (usually after like a day)
etain both cases, something is shoved in the bookmarks2 entry to say "this MUC is broken", which disengages the fanciness until you remove that by manually rejoining and re-adding the bookmarks2 entry
jonas’eta, I’m sure I can read that in the document later on, but what happens if the user sends a message while they are not fully connected?
etajonas’, what do you mean by "not fully connected"
jonas’eta, the server is currently in the process of retrying to get you connected
jonas’eta, the server is currently in the process of retrying to get you connected to the MUC
etajonas’, you get an error of type "wait"
etathe one smoking gun might be if current clients decide to rejoin the MUC in this case, which would suck a lot
etawell, actually, no it really wouldnt'
etawell, actually, no it really wouldn't
jonas’that depends on the specific condition, but a server could easily eat rejoins away in such cases.
alexishas joined
adiaholic_has left
adiaholic_has joined
etajonas’, it kinda does
etaif you attempt to rejoin whilst in the `Reconnecting` state, what happens is it marks you as "waiting to rejoin", eats your presence, and sends you a "experiencing connection issues" message (for conformant clients)
etaif it manages to get you to join, it forwards you the recipient list and then does the "intelligent catchup" process
etaactually wait, no, it wouldn't do that because you'd be expected to do MAM anyway, so scratch that
etathe nice thing is, if this XEP actually becomes a thing the UX will probably be better than something like matrix
etabecause you'll get an explicit "experiencing connection issues" display in your client's UI
eta(which I think is a lot nicer than just sending and not getting any messages back until s2s reconnects and everything floods back in)
etaalso, there's no requirement to implement a bloody complicated MIX server
etalike all you need on the conference service side of things is MUC, unique and stable stanza IDs, (MUC Self-Ping optimization, MAM)
jonas’it makes MUC better, but it doesn’t solve other problems of MUC ;)
etaso I can write my transports and have them work :p
jonas’in fact, this is something MIX also still needs to solve, so I think that work is valuable
etajonas’, what are the other problems though?!
etaoh, MIX
etanvm
jonas’no, your proposed thing
etaokay, what other problems are there
jonas’try to address a specific resource of a participant in a MUC
etawhat's the usecase for that?
jonas’the entire multi-session nick hack which isn’t written down anywhere normative
jonas’eta, sending IQs
etaah
etaoh yeah, re nicks, you can't specify one on join any more
etait forces it to be your bookmarks2 one if you have one in bookmarks2
jonas’I need to step away for a bit, I’m having a hard time to concentrate on anything
etasure
etaI take your point that there are other problems with MUC though :p
eta(but there can be more specs for that)
stpeterhas joined
stpeterhas left
sonnyhas left
sonnyhas joined
mukt2has joined
Wojtekhas left
Lancehas joined
larmahas left
larmahas joined
sonnyhas left
eevvoorhas left
edhelasthere's always other problems with MUC :p
eevvoorhas joined
DanielWhat do we need muc for anyway?
MattJAre you going to say... XEP-0033? :)
Andrzejhas joined
ZashYES
DanielFor smaller groups I can certainly see the appeal
Andrzejhas left
Andrzejhas joined
ZashWould be interesting to see that
mukt2has left
lorddavidiiihas left
krauqhas left
krauqhas joined
mimi89999has left
edhelaschatrooms without MUC 🤔
edhelasit's a bit the difference between mailing lists and chain-answered-emails
Zashexactly that
moparisthebesta, somewhat major server implemented XEP-0033 recently (jmp.chat/cheogram.com) but no support in Conversations (or most/all clients?) yet
Lancehas left
etaah yes
etagroup emails
etathat very functional solution that never results in people getting confused ever
edhelascan't wait for XMPP Chatrooms over SMTP
HolgerFrom 0313's changelog:
> Split preferences protocol into a separate document
Which document did they go into?
ZashHolger: New ones, via the inbox. (Council voted it)
HolgerAh, thx.
ZashDunno if Editor has processed them yet
lovetoxhas joined
jonas’they haven’t been voted into existence yet
jonas’Zash is on-list on them
ZashOh right
jonas’*hinthint* if you vote properly within the next few minutes, they might make today’s editor window *hinthint*
Lancehas joined
mimi89999has joined
bearhas left
neshtaxmpphas left
marchas left
marchas joined
sonnyhas joined
govanifyhas left
govanifyhas joined
DebXWoodyhas joined
winfriedhas left
winfriedhas joined
DebXWoodyhas left
sonnyhas left
sonnyhas joined
DebXWoodyhas joined
lovetoxhas left
sonnyhas left
Steve Killehas left
amuza@riseup.nethas joined
marchas left
bearhas joined
sonnyhas joined
winfriedhas left
winfriedhas joined
Steve Killehas joined
jonas’has left
jonas’has joined
sonnyhas left
sonnyhas joined
Wojtekhas joined
alexishas left
sonnyhas left
marchas joined
Wojtekhas left
sonnyhas joined
krauqhas left
Wojtekhas joined
neshtaxmpphas joined
sonnyhas left
Dele Olajidehas left
krauqhas joined
alexishas joined
neshtaxmpphas left
lovetoxhas joined
mukt2has joined
sonnyhas joined
Wojteketa - out of curiosity - why not push for MIX addotion, instaed of putting another patch on a MUC?
etaWojtek, I think MIX is overengineered
Wojtekand yet another patch on (kinda broken) MUC is better?
moparisthebestonly one can be used without all servers upgrading at once
eta^
etaMIX isn't backwards-compatible with MUC
etaMUC is a very simple standard, and I like that
jonas’Wojtek, MIX also has exactly the same issue
jonas’(not quite exactly, but well)
alexishas left
jonas’eta, MIX does have a MUC compatibility layer which I’d deem "good enough" for a soft transition
etajonas’, okay, but also
Wojteketa: XEP-0408?
etaMIX creates an ecosystem split where half the users still have a crap experience
moparisthebestin tigase's defense they *actually* put in the work and seem to have made a seemingly working implementation, I'll have to update https://www.moparisthebest.com/mix/
etaeven with a compatibility layer
jonas’eta, that’s life.
etajonas’, no, but it doesn't have to be this way
krauqhas left
krauqhas joined
jonas’eta, yes, hence I’d actually suggest putting energy into MIX -- but I don’t blame *you*, because the work you’re doing we need for MIX, too
jonas’we discussed about that in this very room just the other day
etayeah, I saw :)
etaWojtek, okay, point taken
Wojteketa, MUC may be a simple standard yet time and time again there are problems with it and (weird ways) to fix that...
jonas’MUC is by no means a simple standard
Wojtek@jonas’ what same issue?
jonas’Wojtek, dealing with s2s outages
jonas’clients need to know about it to sync their archive with the remote MAM (if we go for remote-archives-only) and/or servers need to sync the user’s MAM and do magic if we allow for user-local archives
Andrzejeta, MUC is simple? try to make it scalable, consistent, etc. you will learn that it is not so simple
etait's simple if you're a transport developer :>
jonas’eta, MUC is a very long document as it stands already. Aside from that, there are hacks upon hacks which aren’t even *documented* there (like the whole multi-session nick stuff, or IQ routing in MUC in general)
Wojtek@jonas’ if we *don't* allow you mean? beacause with local archive each time there is a new message it's delivered to local archive which eliminates issue with s2s outages
etaand MIX solves this problem?
jonas’Wojtek, no, if we *do* allow.
jonas’Wojtek, that’s not correct. what if the s2s between MIX and user server is down?
jonas’eta, yes, because MSN (multi-session nicks) as well as IQ routing (by having each resource addressable) are both well-defined in MIX
Wojtekthen your local archive won't get the message, but you also won't be able to query it ;-)
jonas’Wojtek, yeah, so you have message loss (bad)
Wojtekbut I get it now
Wojtekstill, I don't recall fallback to query remote server if `urn:xmpp:mix:pam:2#archive` was advertised
jonas’it’s a rather tricky thing to solve. It’s not just that servers do MAM syncs among each other. To ensure correct order of message delivery, servers will also have to do replay from MAM as well as queue "live" messages
jonas’Wojtek, sorry, I lack context, what does `urn:xmpp:mix:pam:2#archive` mean and who would fallback to what?
Wojtek"Archive of MIX channel messages MAY be performed by the participant's server. When this is done, the capability is advertized to MIX clients using the 'urn:xmpp:mix:pam:2#archive' feature. If archive is provided it **MUST always be used**, so that where a message is sent to the participant's server and discarded because there are no active clients, it will still be archived. This means that when archiving is provided, the messages will be available in the local archive and can be picked up by clients when they come online. "
sonnyhas left
Andrzej@jonas’ simples solution for s2s issues would be stream management over s2s, or force MIX to add stable-id of a last message which was sent, so that users server MAM could fill that and deliver "lost" messages as a normal MIX message with `<delay/>` element in them
etaAndrzej, my proposed solution does the stable-id thing, sorta
jonas’Andrzej, no, stream-management is not sufficient
jonas’stream management will have limits because servers won’t queue forever.
jonas’Wojtek, the text you quoted is exactly the problematic part. It claims that the user’s archive is the gold standard, but in fact it’ll have gaps without additional measures.
jonas’Andrzej, what you propose is one of the ways to do it, but then the user server becomes quite complex. It needs to do MAM queries, backfill the local archive (which it may not be able to even to, because it’d have to insert into MAM at an earlier point, violating one of the MAM guarantees!), it has to buffer all "live" messages from the MIX to be able to replay MAM first in order to provide in-order delivery of all stanzas from the MIX.
jonas’and it needs to do that across all pubsub-nodes the user has subscribed to on the MIX, too
Andrzej@jonas’ we will have gaps, but it was discussed at the summit and the simples solution to add to the message stable-id of a previous message was suggested (by Kev if I recall)
jonas’and then the client would be responsible for filling the gap in its local archive?
Andrzej@jonas’ why it needs to insert those new entries in the past? just add them at the end with `<delay/>` element in them
mukt2has left
Andrzejthen MAM would be just log of a messages which you have received and delay timestamps would allow clients to assign those messages in proper order
jonas’which clients don’t do generally
jonas’and I’m also not sure if that’d be acceptable
etaWojtek, XEP-0408 doesn't really say much
WojtekI know that it's the problem, but it says that if there is local archive the user *MUST* use it (so no queryign from MIX MAM)
jonas’Wojtek, hence the debate about that particular text :)
jonas’eta, needs implementations. but conceptually, it can easily work.
etaokay, so MIX removes some hacks that you need to make MUC work
etaI mean I don't think the problems with MUC are bad enough to justify scrapping it entirely
etaor rather, to justify the ecosystem split having 2 competing standards would cause
jonas’that is your opinion and you can have it :)
Wojtek:-)
etaindeed!
etaif people want to implement MIX though, go ahead! part of why XMPP is great is precisely that people can have different ideas
Wojtekand having many things of doing something is kinda "XMPP way" ;-)
Andrzejeta, for mobile devices (ie. iOS) using MUC requires a lot of hacks
jonas’though I *do* find it amusing, that the often-complained-about required user-server support for MIX is now coming for MUC ;)
Wojtekfor me it seems that MUC is basically mutating into MIX, in stages...
etaAndrzej, are a lot of hacks bad though? :p
WojtekYES :-P
etaAndrzej, I mean the followup XEP I was going to write is a spec for doing push notifications
etaif the server has a resource constantly joined to the MUC, it can receive messages, match them against a set of rules / regexes, and then forward the message to the client
Andrzejeta, with filtering I hope?
jonas’eta, what about E2EE?
etaAndrzej, yeah, I want to essentially rip off matrix's push rules system
mukt2has joined
etajonas’, you'd have to either (a) send every message or (b) include a separate <mentions/> element or w/e
etaand deal with the privacy implications of (b)
Wojtek> if the server has a resource constantly joined to the MUC, it can receive messages, match them against a set of rules / regexes, and then forward the message to the client
so, basically permanent member subscription? like in... MIX? ;-)
etaalthough *no* messenger can deal with the e2ee problem :)
Andrzejeta, if you want to write something like that please check https://xeps.tigase.net//docs/push-notifications/filters as this could be useful
lskdjfhas left
etaAndrzej, issue I have with that is, what does "mentioned" mean
etado I get a notification any time someone says "details"? ;P
Mikaelahas left
moparisthebestit means you can silently eat the mobile battery of everyone you are in a channel with of course :)
lskdjfhas joined
Andrzejmentioned means that your nickname was mentioned in a message
etaAndrzej, no, sure, but how are you matching
etaif your test is `string.contains(nick)` it's going to break for me :)
Andrzejcontains and check if before and after there is no alphanumeric character
etaah, good
etathat aside, though, yeah, that XEP looks very similar
etaWojtek, yeah, exactly like in MIX :p
AndrzejI was suggesting to consider just requirements from our XEP (and syntax if that would be useful)
etalike I don't think MUC's current semantics are ideal at all
etaWojtek, the difference is my proposed XEP doesn't require the MUC service to support much more
Andrzejbut requires local server to keep a persistent session for you
etayeah
Andrzejwith S2S issues, reconnections, MUC restarts, etc. this can be problematic
etaAndrzej, that's what the whole XEP is about
etayou could even extend it to have local archiving semantics similar to your MIX implementation
etait just won't do that initially because that's a bit of a hard sell for some server operators
etagenerally my problem with MIX is it doesn't really obey Postel's Law (https://en.wikipedia.org/wiki/Robustness_principle): it requires there to be a shiny new MIX service out there to get any of the benefits
etawhereas trying to patch MUC on the server side will improve experience for ~90% of users without them having to change client or MUC service
etathat said, for non federating environments, MIX is unquestionably better
Mikaelahas joined
Wojtekand then you end up in a situaiton when some server support that and some not and some user will have different experience than others... and then everyone complain again that it's impossible to have more-or-less consisten experience with XMPP and jump on the matrix badwagon
moparisthebestnot sure that's the right law, it requires a flag-day, which never ends up happening
etaWojtek: well no, you make it part of the compliance tester
etaalso I mean, MIX has the same issue!
eta(in fact it's worse)
moparisthebesthuh TIL that flag day was also Postel's https://tools.ietf.org/html/rfc801 :)
sonnyhas joined
Wojtekcompliance server is run by a private person and not XSF… and it's kinda arbitrary - it requires XEP-0215 yet compliance suite doesn't mention this particular XEP...
jonas’it also doesn’t say XMPP or XSF compliance ;)
DanielThe compliance tester is just 4 month ahead of time
etaWojtek: well, I mean I'd be interested to hear your solution here
etafragmentation is definitely an issue, but I'm not sure there is an obvious magic bullet
mukt2has left
lorddavidiiihas joined
mukt2has joined
sonnyhas left
neshtaxmpphas joined
papatutuwawahas left
papatutuwawahas joined
debaclehas joined
lovetoxeta, the idea to make it dependend on bookmarks2 seems like a sure way implementation gets delayed very long
lovetoxthere is no server that supports bookmarks2 in a way that client would want to use it
etalovetox: but bookmarks2 defines a private XML conversion path
etalovetox: oh? what are the issues with bookmarks2?
lovetoxhm? i didnt say there where issues with bookmarks2, only that no server supports it
etaah
lovetoxand bookmarks2 in turn depends on other XEPs that servers dont support
jonas’does it?
lovetoxlike the recent "max" change in pubsub
Wojtek> it also doesn’t say XMPP or XSF compliance ;)
yet it seems that everyone considers it as such ;-) and eta proposed using it as a mean to promote XEPs :-)
krauqhas left
Wojtek> The compliance tester is just 4 month ahead of time
hence "arbitrary" - you can do with compliance tester whatever you want as it's not XMPP/XSF :-)
etaWojtek: hey, feel free to make a Siskin compliance tester :p
WojtekSiskin is client, not server ;-)
etaWojtek: no, but the other tester is "the Conversations compliance tester", because it tests whether the server works well with Conversations
Zash"A thing that tests whether servers are tuned for Siskin"
etaWojtek: like, more compliance testers would be great!
etaI'm not saying Daniel's one has to be the One True Tester
Wojteketa yet you proposed to promote certain specification via compliance tester
Andrzejso is it really a "compliance tester" or "compatibility tester"?
krauqhas joined
Yagizahas left
etaWojtek: well, okay, that's assuming Conversations uses said specification
ZashAndrzej: I was just going to say ... the later.
etaWojtek: perhaps I'm a bit too optimistic in that regard :p
ZashYou could even fork it, tune it to your own clients requirements.
sonnyhas joined
sonnyhas left
ZashOr make an ultimate every client compatibility tester
Andrzejhas left
Andrzejhas joined
etaWojtek: my point is just that the conversations compliance tester seemed to do a relatively okay job of driving AV call adoption by servers
Zash(along with a client needing it and users wanting the call feature)
etatrue :p
alameyohas left
alameyohas joined
sonnyhas joined
sonnyhas left
etacurses at xef/xeps
eta> element header: validity error : Element header content does not follow the DTD, expecting (title , abstract , legal , number , status , lastcall* , interim* , type , sig , approver* , dependencies , supersedes , supersededby , shortname , schemaloc* , registry? , discuss? , expires? , author+ , revision+ , councilnote?), got (title abstract legal number status type sig approver dependencies supersedes supersededby author shortname revision )
</header>
Andrzejhas left
etaoh my god
etathey have to be in the correct order
etathat's ridiculous
xsfhas left
xsfhas joined
bearhas left
sonnyhas joined
ZashPraise schema validation!
jonas’eta, I recommend using xep-template.xml
etajonas’, ...now you tell me
jonas’I told you to ask :D
etacopies & pastes
etaI've already written an intro, which is good
jonas’eta, next time, ping me directly, I’m happy to help before things become an annoyance
etanot having to refer to XEP-0001 all the damn time is nice though :)
ZashBut have you considered implementing an elaborate document processing pipeline that turns plain text into xep-xml?!
jonas’GPT-3?
ZashOh no
Andrzejhas joined
jonas’hmmm
moparisthebest*spits out machine generated XEP* hmm looks alot like matrix
ZashYou're holding it upsidedown?
jonas’requests OpenAI beta access
moparisthebestI turned it upside down and now it just looks like a blockchain
jonas’let’s see if they give it to me
sonnyhas left
sonnyhas joined
Alexlets kick off our member meeting
Zash!
moparisthebest\o/
Alexbangs the gavel
jonas’oh right! and I’m even around!
Alexhere is our Agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25
Alex1) Call for Quorum
Alexas you can see 34 members voted via Memberbot, so we have a quorum
Alex2) Items Subject to a Vote
Alexnew and returning members, you can see all applicants on this page:
https://wiki.xmpp.org/web/Membership_Applications_Q3_2020
Alex3) Opportunity for XSF Members to Vote in the Meeting
Alexanyone here who has not voted yet and wants to do so now?
sonnyhas left
Alexlooks like none
AlexI will shutdown the bot then and start working on the results
Andrzejhas left
sonnyhas joined
lovetoxhas left
lovetoxhas joined
Guus🥁
thorstenhas left
Alex4) Announcement of Voting Results
Alexwhen you reload the page at:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25#Announcement_of_Voting_Results
you can see the results
Alexall new and returning members are accepted. Congrats to everone, and welcome to our new members
stpeterhas joined
stpeterhas left
Alex5) ny Other Business?
jonas’None from me
GuusNone here
jonas’except: congratulations to everyone and thanks to our Secretary for the duty
Alex6) Formal Adjournment
AlexI motion that we adjourn
Zash+1
Alexbangs the gavel
Alexthanks everyone
GuusThanks Alex !
moparisthebest🔨️ thanks Alex
ZashThanks Alex. Congrats to all.
Alexwill update the memberlist and mailing list tomorrow morning
AlexThanks to Dave for updating Memberbot. Was running very smoothly this time ;-)
sonnyhas left
sonnyhas joined
lovetoxhas left
jonas’has left
winfriedhas left
winfriedhas joined
Andrzejhas joined
sonnyhas left
eevvoorhas left
bearhas joined
sonnyhas joined
DebXWoodyhas left
jonas’has joined
neshtaxmpphas left
winfriedhas left
winfriedhas joined
sonnyhas left
Andrzejhas left
adiaholic_has left
adiaholic_has joined
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
adiaholic_has left
adiaholic_has joined
Nekithas joined
jonas’has left
jonas’has joined
marchas left
jonas’Special congrats to (!)!XSF_Martin and Holger :)
MartinThanks 😃
Martinhas left
MattJThe irony is that the original "XSF Martin" that caused you to switch to that nick... I'm pretty sure he was never a member of the XSF :)
jonas’not?
jonas’but he was in board, right?
eta. o O ( I should join the XSF )
MattJjonas’: yes
jonas’ok, that explains my assumptions (and I suppose also mdosch’s)
etahow do clients typically advertise support for some XEP?
jonas’eta, XEP-0030
APachhas left
etajonas’, right, so the server is expected to do the whole entity caps dance and disco#info query it?
jonas’yes, servers do that anyways tho
jonas’for PEP
etaoh, okay, so that's something we can build on
jonas’so just state that the client has to implement XEP-0115 and go ahead
etaadds more dependencies
marchas joined
sonnyhas joined
sonnyhas left
thorstenhas joined
thorstenhas left
Andrzejhas left
thorstenhas joined
sonnyhas joined
sonnyhas left
etaright, after 20 minutes of XML wrangling I've managed to make a TOC
etaactual spec content still to follow >_>
eta(well, there's an intro, requirements, and MUC failure modes section)