Well 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
dwd
lovetox, You're not allowed to send data to the FBI; it would be illegal under the GDPR.
sonnyhas left
dwd
moparisthebest, 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").
dwd
moparisthebest, (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
Alex
Memberbot 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
MattJ
Just 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
eta
btw, 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 :)
eta
the 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
eta
MUC 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
moparisthebest
eta: is that prosody mod_minimix ?
jonasā
but it improves the situation
eta
jonasā, do tell
eta
what issues remain?
eta
moparisthebest, 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
Zash
jonasā, wanna write down all the issues on the wiki or such?
jonasā
Zash, -EBUSY
Zash
-WSADFACE
eta
jonasā, 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
eta
if 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?
let's say you're disconnected for an extended period and miss out on like 1000 lines of history
jonasā
yeah
eta
now the server will perform MAM to filter through that to see if any of those lines contain your nickname (for push purposes)
eta
but 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?
eta
yeah, so there's a limit
jonasā
I donāt like that
jonasā
donāt hide issues if you canāt hide them completely
Zash
Will perform MAM ... when?
Zash
Periodically?
jonasā
Zash, after MUC self-ping errored
eta
Zash, upon reconnect
Zash
Polling? Hmmmm, not sure if like
eta
Zash, 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
eta
Zash, also this is a strict improvement upon the status quo, right
jonasā
no
eta
clients currently have to poll anyways
eta
it'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
eta
jonasā, it's not hidden
jonasā
how is it not hidden?
eta
jonasā, 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.
eta
no, they won't
eta
it kicks you in that case
jonasā
hue?
undefinedhas left
jonasā
what about the MAM stuff you said earlier then?
eta
so it tries to do a catchup
jonasā
ah, and if thatās too much, you get kicked
jonasā
makes sense
eta
yeah
eta
and 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)
Zash
current retry logic: none
MattJ
Count 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
eta
I mean I'll write this up into a proper protoXEP at some point soon once I figure out how to do that
if there are no glaring issues with it, I'll probably forge ahead with trying to write prosody modules
eta
oh yeah, the other thing I forgot to mention is
jonasā
eta, ok, that makes much more sense.
eta
this 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?
eta
basically the flow is without a bookmarks2 entry for a room, you don't get any server fanciness
MattJ
jonasā, what needs cleanup specifically?
eta
so 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)
MattJ
Ok, that wasn't on my todo but I can look into it
MattJ
Probably not for a couple of weeks though
jonasā
MattJ, I see, thanks nontheless
jonasā
nothing too urgent anyways
eta
once 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)✎
eta
once 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) ✏
eta
in 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?
eta
jonasā, 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 ✏
eta
jonasā, you get an error of type "wait"
eta
the one smoking gun might be if current clients decide to rejoin the MUC in this case, which would suck a lot
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
eta
jonasā, it kinda does
eta
if 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)
eta
if it manages to get you to join, it forwards you the recipient list and then does the "intelligent catchup" process
eta
actually wait, no, it wouldn't do that because you'd be expected to do MAM anyway, so scratch that
the nice thing is, if this XEP actually becomes a thing the UX will probably be better than something like matrix
eta
because 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)
eta
also, there's no requirement to implement a bloody complicated MIX server
eta
like 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 ;)
eta
so 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
eta
jonasā, what are the other problems though?!
eta
oh, MIX
eta
nvm
jonasā
no, your proposed thing
eta
okay, what other problems are there
jonasā
try to address a specific resource of a participant in a MUC
eta
what's the usecase for that?
jonasā
the entire multi-session nick hack which isnāt written down anywhere normative
jonasā
eta, sending IQs
eta
ah
eta
oh yeah, re nicks, you can't specify one on join any more
eta
it 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
eta
sure
eta
I 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
edhelas
there's always other problems with MUC :p
eevvoorhas joined
Daniel
What do we need muc for anyway?
MattJ
Are you going to say... XEP-0033? :)
Andrzejhas joined
Zash
YES
Daniel
For smaller groups I can certainly see the appeal
Andrzejhas left
Andrzejhas joined
Zash
Would be interesting to see that
mukt2has left
lorddavidiiihas left
krauqhas left
krauqhas joined
mimi89999has left
edhelas
chatrooms without MUC š¤
edhelas
it's a bit the difference between mailing lists and chain-answered-emails
Zash
exactly that
moparisthebest
a, somewhat major server implemented XEP-0033 recently (jmp.chat/cheogram.com) but no support in Conversations (or most/all clients?) yet
Lancehas left
eta
ah yes
eta
group emails
eta
that very functional solution that never results in people getting confused ever
edhelas
can't wait for XMPP Chatrooms over SMTP
Holger
From 0313's changelog:
> Split preferences protocol into a separate document
Which document did they go into?
Zash
Holger: New ones, via the inbox. (Council voted it)
Holger
Ah, thx.
Zash
Dunno if Editor has processed them yet
lovetoxhas joined
jonasā
they havenāt been voted into existence yet
jonasā
Zash is on-list on them
Zash
Oh 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
Wojtek
eta - out of curiosity - why not push for MIX addotion, instaed of putting another patch on a MUC?
eta
Wojtek, I think MIX is overengineered
Wojtek
and yet another patch on (kinda broken) MUC is better?
moparisthebest
only one can be used without all servers upgrading at once
eta
^
eta
MIX isn't backwards-compatible with MUC
eta
MUC 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
eta
jonasā, okay, but also
Wojtek
eta: XEP-0408?
eta
MIX creates an ecosystem split where half the users still have a crap experience
moparisthebest
in 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/
eta
even with a compatibility layer
jonasā
eta, thatās life.
eta
jonasā, 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
eta
yeah, I saw :)
eta
Wojtek, okay, point taken
Wojtek
eta, 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
Andrzej
eta, MUC is simple? try to make it scalable, consistent, etc. you will learn that it is not so simple
eta
it'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
eta
and 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
Wojtek
then 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)
Wojtek
but I get it now
Wojtek
still, 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
eta
Andrzej, 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
Andrzej
then 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
eta
Wojtek, XEP-0408 doesn't really say much
Wojtek
I 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.
eta
okay, so MIX removes some hacks that you need to make MUC work
eta
I mean I don't think the problems with MUC are bad enough to justify scrapping it entirely
eta
or rather, to justify the ecosystem split having 2 competing standards would cause
jonasā
that is your opinion and you can have it :)
Wojtek
:-)
eta
indeed!
eta
if people want to implement MIX though, go ahead! part of why XMPP is great is precisely that people can have different ideas
Wojtek
and having many things of doing something is kinda "XMPP way" ;-)
Andrzej
eta, 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 ;)
Wojtek
for me it seems that MUC is basically mutating into MIX, in stages...
eta
Andrzej, are a lot of hacks bad though? :p
Wojtek
YES :-P
eta
Andrzej, I mean the followup XEP I was going to write is a spec for doing push notifications
eta
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
Andrzej
eta, with filtering I hope?
jonasā
eta, what about E2EE?
eta
Andrzej, yeah, I want to essentially rip off matrix's push rules system
mukt2has joined
eta
jonasā, you'd have to either (a) send every message or (b) include a separate <mentions/> element or w/e
eta
and 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? ;-)
eta
although *no* messenger can deal with the e2ee problem :)
Andrzej
eta, 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
eta
Andrzej, issue I have with that is, what does "mentioned" mean
eta
do I get a notification any time someone says "details"? ;P
Mikaelahas left
moparisthebest
it means you can silently eat the mobile battery of everyone you are in a channel with of course :)
lskdjfhas joined
Andrzej
mentioned means that your nickname was mentioned in a message
eta
Andrzej, no, sure, but how are you matching
eta
if your test is `string.contains(nick)` it's going to break for me :)
Andrzej
contains and check if before and after there is no alphanumeric character
eta
ah, good
eta
that aside, though, yeah, that XEP looks very similar
eta
Wojtek, yeah, exactly like in MIX :p
Andrzej
I was suggesting to consider just requirements from our XEP (and syntax if that would be useful)
eta
like I don't think MUC's current semantics are ideal at all
eta
Wojtek, the difference is my proposed XEP doesn't require the MUC service to support much more
Andrzej
but requires local server to keep a persistent session for you
eta
yeah
Andrzej
with S2S issues, reconnections, MUC restarts, etc. this can be problematic
eta
Andrzej, that's what the whole XEP is about
eta
you could even extend it to have local archiving semantics similar to your MIX implementation
eta
it just won't do that initially because that's a bit of a hard sell for some server operators
eta
generally 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
eta
whereas trying to patch MUC on the server side will improve experience for ~90% of users without them having to change client or MUC service
eta
that said, for non federating environments, MIX is unquestionably better
Mikaelahas joined
Wojtek
and 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
moparisthebest
not sure that's the right law, it requires a flag-day, which never ends up happening
Wojtek: well no, you make it part of the compliance tester
eta
also I mean, MIX has the same issue!
eta
(in fact it's worse)
moparisthebest
huh TIL that flag day was also Postel's https://tools.ietf.org/html/rfc801 :)
sonnyhas joined
Wojtek
compliance 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 ;)
Daniel
The compliance tester is just 4 month ahead of time
eta
Wojtek: well, I mean I'd be interested to hear your solution here
eta
fragmentation 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
lovetox
eta, the idea to make it dependend on bookmarks2 seems like a sure way implementation gets delayed very long
lovetox
there is no server that supports bookmarks2 in a way that client would want to use it
eta
lovetox: but bookmarks2 defines a private XML conversion path
eta
lovetox: oh? what are the issues with bookmarks2?
lovetox
hm? i didnt say there where issues with bookmarks2, only that no server supports it
eta
ah
lovetox
and bookmarks2 in turn depends on other XEPs that servers dont support
jonasā
does it?
lovetox
like 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 :-)
eta
Wojtek: hey, feel free to make a Siskin compliance tester :p
Wojtek
Siskin is client, not server ;-)
eta
Wojtek: 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"
eta
Wojtek: like, more compliance testers would be great!
eta
I'm not saying Daniel's one has to be the One True Tester
Wojtek
eta yet you proposed to promote certain specification via compliance tester
Andrzej
so is it really a "compliance tester" or "compatibility tester"?
krauqhas joined
Yagizahas left
eta
Wojtek: well, okay, that's assuming Conversations uses said specification
Zash
Andrzej: I was just going to say ... the later.
eta
Wojtek: perhaps I'm a bit too optimistic in that regard :p
Zash
You could even fork it, tune it to your own clients requirements.
sonnyhas joined
sonnyhas left
Zash
Or make an ultimate every client compatibility tester
Andrzejhas left
Andrzejhas joined
eta
Wojtek: 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)
eta
true :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
eta
oh my god
eta
they have to be in the correct order
eta
that's ridiculous
xsfhas left
xsfhas joined
bearhas left
sonnyhas joined
Zash
Praise schema validation!
jonasā
eta, I recommend using xep-template.xml
eta
jonasā, ...now you tell me
jonasā
I told you to ask :D
etacopies & pastes
eta
I'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
eta
not having to refer to XEP-0001 all the damn time is nice though :)
Zash
But have you considered implementing an elaborate document processing pipeline that turns plain text into xep-xml?!
jonasā
GPT-3?
Zash
Oh no
Andrzejhas joined
jonasā
hmmm
moparisthebest
*spits out machine generated XEP* hmm looks alot like matrix
Zash
You're holding it upsidedown?
jonasārequests OpenAI beta access
moparisthebest
I 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
Alex
lets kick off our member meeting
Zash
!
moparisthebest
\o/
Alexbangs the gavel
jonasā
oh right! and Iām even around!
Alex
here is our Agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25
Alex
1) Call for Quorum
Alex
as you can see 34 members voted via Memberbot, so we have a quorum
Alex
2) Items Subject to a Vote
Alex
new and returning members, you can see all applicants on this page:
https://wiki.xmpp.org/web/Membership_Applications_Q3_2020
Alex
3) Opportunity for XSF Members to Vote in the Meeting
Alex
anyone here who has not voted yet and wants to do so now?
sonnyhas left
Alex
looks like none
Alex
I will shutdown the bot then and start working on the results
Andrzejhas left
sonnyhas joined
lovetoxhas left
lovetoxhas joined
Guus
š„
thorstenhas left
Alex
4) Announcement of Voting Results
Alex
when you reload the page at:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-08-25#Announcement_of_Voting_Results
you can see the results
Alex
all new and returning members are accepted. Congrats to everone, and welcome to our new members
stpeterhas joined
stpeterhas left
Alex
5) ny Other Business?
jonasā
None from me
Guus
None here
jonasā
except: congratulations to everyone and thanks to our Secretary for the duty
Alex
6) Formal Adjournment
Alex
I motion that we adjourn
Zash
+1
Alexbangs the gavel
Alex
thanks everyone
Guus
Thanks Alex !
moparisthebest
šØļø thanks Alex
Zash
Thanks Alex. Congrats to all.
Alex
will update the memberlist and mailing list tomorrow morning
Alex
Thanks 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 :)
Martin
Thanks š
Martinhas left
MattJ
The 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 )
MattJ
jonasā: yes
jonasā
ok, that explains my assumptions (and I suppose also mdoschās)
eta
how do clients typically advertise support for some XEP?
jonasā
eta, XEP-0030
APachhas left
eta
jonasā, 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
eta
oh, 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
eta
right, after 20 minutes of XML wrangling I've managed to make a TOC
eta
actual spec content still to follow >_>
eta
(well, there's an intro, requirements, and MUC failure modes section)