There might also be some merit in having a structured mapping between XEPs and feature identities.
adiaholichas left
LNJhas joined
kokonoehas left
kokonoehas joined
jabberjockehas left
APachhas left
ajhas joined
Nekithas left
Nekithas joined
APachhas joined
adiaholichas joined
zachhas left
zachhas joined
Zashhas joined
wurstsalathas joined
j.rhas left
j.rhas joined
LNJhas left
Alexhas joined
archas left
archas joined
karoshihas joined
ralphm
I am curious if including the disco section in every XEP actually triggers developers to make sure they handle the discovery bits while implementing.
winfriedhas left
winfriedhas joined
jonas’
dwd, why would you need to change XEP-0001 for that?
Zash
I'm going to assume that not including it would lead to nobody implementing disco bits.
jonas’
I agree with Zash
ralphm
Indeed
ralphm
While doing some research, I came across the ancient XEP-0038. It uses the following in that section:
“To find out if an entity supports Jabber Icon Styles, look for the feature category of http://jabber.org/protocol/icon-styles using jabber:iq:browse or http://jabber.org/protocol/disco. The same feature category can be used with feature negotiation.”
ralphm
As it doesn't include any example protocol flow, this feels much easier to "miss" while scanning the spec.
zachhas left
zachhas joined
jonas’
+1
Daniel
I mean I said this yesterday. But nobody reads xeps. Everyone just copy pastes samples
ralphm
(also funny that it refers to the pre-disco protocol)
Tobiashas joined
winfriedhas left
winfriedhas joined
Zash
On the other hand, if you include too much boilerplate you will likely miss parts too. Hence why you discover something new each time you read XEP-0060 or XEP-0045
Daniel
Zash: I'm not sure that xep60 and 45 would have been better w/o the disco bits
Daniel
But I get the point...
ralphm
I'm glad that for MIX we already have a split now.
Seve
> I'm going to assume that not including it would lead to nobody implementing disco bits.
I think that way as well
ralphm
jonas’: by the way, thanks for linking to that old mail of yours on References. Taking that into account as well, while working on my overview of pointing to things.
jonas’
ralphm, \o/ :)
karoshihas left
karoshihas joined
Daniel
I wish the open source community would be more enthusiastic about MIX
jonas’
Daniel, I am extremely enthusiastic
jonas’
I need a server to play with though :)
winfriedhas left
Daniel
jonas’: any ejabberd should do
jonas’
I’m ready to write the aioxmpp code, and I’m ready to make Muclumbus support it
jonas’
oh?
winfriedhas joined
jonas’
I totally missed that
Daniel
Ask Holger if you don't want to install your own
jonas’
they have docker images, I’m fine with that
jonas’
was MIX support in the newsletter?
Daniel
jonas’: not that _we_ are currently stuck at where to put the channels if not the roster
Daniel
That part is not implemented in ejabberd because it's stupid
Daniel
But normal join / sending messages works
jonas’
Daniel, PEP-ish thing?
Daniel
jonas’: yes. Probably
jonas’
PEP with server-side side-effects seems like a great thing in general.
Daniel
But someone needs to write down the syntax
ralphm
Daniel: I think the issue is that it is perceived as really complex and involved. While there is a certain truth to that, the problems it tries to attack aren't really simple, to be honest. However, I believe that there is a simple subset that would be a good start for getting implementations.
Daniel
ralphm: yes. Full ack
jonas’
ISTM I have something to do during my vacation in 2w :)
ralphm
As an example, I don't think you /need/ roster integration from the get go.
Daniel
jonas’: I mean really an exploratory implementation can be written on a weekend
jonas’
Daniel, not with my weekends at the moment ;)
Daniel
And that includes reading the xep
ralphm
Anyway, I'm currently focussed on rich messaging and pointing to things. MIX might be my next focus.
Daniel
Client side I mean
ralphm
Daniel: yes. At VEON we also had a simple implementation relatively quickly. On the server side, too.
Daniel
Yeah. I don't think it took zinid too long either
pdurbinhas left
Daniel
I mean I said this before but to me the cool thing about MIX is, that while I see the need for it, there is no urgency to ship it, so for once we the community can actually use the experimental state as what it was intented to, and do exploratory implementations that won't be shipped
zachhas left
zachhas joined
ralphm
And if you want some kind of backwards compat, maybe it is worthwhile starting with a fresh MIX implementation, and then having a MUC legacy interface to it.
ralphm
(as opposed to the other way around)
remkohas joined
APachhas left
kokonoehas left
kokonoehas joined
Steve Killehas left
APachhas joined
Steve Killehas joined
winfriedhas left
winfriedhas joined
adiaholichas left
adiaholichas joined
jabberjockehas joined
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
mr.fisterhas left
dwd
jonas’, The schema for XEPs is in XEP-0001, hence that involvement.
dwd
ralphm, I had a working MIX-with-MUC-interface in a few days at Threads.
jonas’
dwd, the schema is not normative, meheard
jonas’
especially since it’s not validated, only the DTD is
zachhas left
zachhas joined
ralphm
dwd: yes, indeed
kokonoehas left
Dele (Mobile)has joined
kokonoehas joined
adiaholichas left
adiaholichas joined
Danielhas left
Danielhas joined
Danielhas left
linkmauvehas joined
Danielhas joined
zachhas left
zachhas joined
Zashhas left
Zashhas joined
Nekithas left
jcbrandhas joined
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
Nekithas joined
adiaholichas left
goffihas left
adiaholichas joined
adiaholichas left
adiaholichas joined
marc_has joined
goffihas joined
kokonoehas left
kokonoehas joined
zachhas left
zachhas joined
marc_has left
marc_has joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
Kev
Ge0rG / ralphm: I think the option we spoke of to have the apply-to children as siblings of the apply-to isn't needed. Reason being that e.g. for LMC the LMC would be the child of the apply-to, and then the LMC can describe where the applicable payloads should reside.
Kev
Am I being dense?
Kev
(r than normal)
jonas’
Kev, having them as siblings was intended for backward compatibility
jonas’
so that we don’t have to change the core LMC wire format
ralphm
Yeah, my feeling was that I have a preference for a sibling
Kev
Was it? That certainly was not what I thought we were discussing.
jonas’
(and don’t have to duplicate that information)
jonas’
that’s what I read from Ge0rGs gist
Kev
I thought we were discussing having the e.g. <body/> outside the <apply-to/>.
jonas’
> - for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed
Kev
I have those words in front of me.
jonas’
I read the "legacy" part as "for backward compat", I may be wrong
Kev
But I think we got confused.
Kev
I think it's ok to have something wrapped by the apply-to, and the thing that's wrapped can say to look outside, if it wants to.
ralphm
Especially because, e.g. for references, in some cases you might attach to another message, and some you don't (because the body is included). Having them in the same place seems better.
jonas’
Kev, makes sense
Ge0rG
Kev: but then we end up with the overengineered <look-outside-for element-name="body" namespace="jabber:client"/> element
Kev
Ge0rG: I think we end up with that whatever happens. Just whether it's going to live inside the LMC or apply-to element.
Kev
(I also don't think it's overengineered)
Ge0rG
It's the obvious generic thing.
Ge0rG
But what happens when:
1. I send a message to a MUC
2. the MUC attaches references
3. I LMC that message
4. the MUC ??? ???✎
Ge0rG
But what happens when:
1. I send a message to a MUC
2. the MUC attaches references
3. I LMC my original message
4. the MUC ??? ??? ✏
ralphm
Parses it again?
Nekithas left
Ge0rG
ralphm: the MUC needs to LMC the attached message, obviously
Kev
Yes. The MUC will need to understand LMC for this to work.
Kev
(Yes was to Ralph)
ralphm
Ah, that is a good point, yes
pdurbinhas joined
Ge0rG
so #4 will be a message attached to two different messages, with different attaching semantics
ralphm
If it doesn't and the room doesn't understand LMC, it would attach to that LMC stanza instead of the original, as it parses the new body element?
APachhas left
Ge0rG
ralphm: yes
Kev
I think what we need (which we need for reactions anyway) is a way of un-applying an apply-to. So the MUC would un-apply its previous references, and apply new ones. To the original stanza.
ralphm
You'd have a chain
Ge0rG
ralphm: a tree
Ge0rG
Kev: would an implicit unapply by applying something new work? With a limit of one application per JID and application type?
Kev
So we need stanza versioning :)
moparisthebesthas left
Kev
I think you want to allow many applications per type, in the case of reactions particularly, but we could always have a 'remove-previous' flag on the application.
ralphm
Kev: yes, we surely need an unattach. But I'm curious about 'unknown' things being attached. Like if we redo LMC to be edits, with a namespace change and the muc service not understanding it (yet)
Ge0rG
Kev: we are overengineering it
Nekithas joined
Ge0rG
This is going to become the MIX of Message References.
ralphm
Dude
Kev
I'm not yet convinced this is over-engineered. It's generic, which isn't necessarily the same. Particularly if we end up with something easier to implement all the edge-cases than doing the under-engineered thing.
Kev
Let's not make it the MUC of Message References :)
Ge0rG
Heh.
wurstsalathas left
wurstsalathas joined
pdurbinhas left
Yagizahas left
Ge0rG
So let's say we do Message Edits by means of stanza versioning. What kind of wire format do you suggest?
Ge0rG
Will it use Attach-To (in a kind of privileged manner, checking the sender JID), or will it use a new, orthogonal syntax?
Kev
The stanza versioning was half-said in jest.
Kev
(Although if we were starting again it's probably the right thing to do)
Ge0rG
There are some aspects I hate about LMC, but they can be changed without touching the wire format
ralphm
I'm not sure. If you want to allow correcting other messages, the wire format wouldn't need to change but the semantics will. To separate them you need to up the version of the namespace.
Ge0rG
ralphm: I argue that we just can introduce a new feature.
Ge0rG
I still see some merit in allowing room admins to change a message, though.
larma
I also had a short chat regarding attach-to/MAM 2.0 yesterday. One thing that came up is that 0333 read markers only mention a single message but apply to many. It seems sensible to not send 10 read marker messages if you open a chat with 10 unread messages, so this one kind of requires being attached to multiple messages
Nekithas left
alameyohas left
ralphm
Ge0rG: how would you introduce the new feature?
alameyohas joined
Ge0rG
larma: good point, but read markers attach to the latest message
Ge0rG
which is a dumb thing in a protocol that lacks any kind of message ordering.
Ge0rG
(I'm speaking of MAM here)
ralphm
larma: the semantics of markers already say you should squash them? A server should only have one?
Ge0rG
ralphm: by "feature" I meant a new var in disco#info
Ge0rG
I've implemented delayed 0184 transmission for MAM yesterday, and that made me realize that even with 1500+ entries in MAM, there is only a handful of not yet sent 0184s
Nekithas joined
ralphm
Ge0rG: if there are clients implement something that ignores lmc if it is not the last, and don't know your new feature, you are not seeing edits?
larma
Current markers suck for MAM 2.0 anyways, but the question is more how a good updated version would probably look like: `<message><mark-read /><attach-to id=A /><attach-to id=B /></message>` and not `<message><mark-read /><attach-to id=A /></message>`+`<message><mark-read /><attach-to id=B /></message>` (the latter one would be required if we only allow to attach to a single message)
ralphm
I don't think you should do read markers for stanzas that attach to others at all
Ge0rG
ralphm: did you just say "resource locking"?
marc_has left
marc_has joined
ralphm
Huh?
Ge0rG
ralphm: in the Carbons+MAM world, there is no way to know which features the receiving client will have.
ralphm
Yes indeed
Ge0rG
ralphm: so yes, if you allow editing older messages on the sending side, the receiving side is not guaranteed to display those as edits
zachhas left
zachhas joined
ralphm
Exactly
Ge0rG
I can only hope that no implementor is dumb enough to just drop the new messages.
ralphm
That'd be disappointing
Ge0rG
ralphm: but bumping the namespace isn't going to improve that in any sensible way.
Ge0rG
this is BTW the part of LMC that I dislike the most.
ralphm
Well, you'd at least see all the things?
Ge0rG
ralphm: what things?
ralphm
If a client doesn't know the new thing it will just display the body?
Ge0rG
yes.
ralphm
So you have 'double' messages
Ge0rG
if a client supports LMC and considers an edit as illegal, it will also just display the body, unless the developer is a huge moron.
Kev
That sounds quite wrong.
ralphm
And judgemental
Ge0rG
So you will have double messages if you do an "illegal" v1 LMC, or if you have a v2 Edit.
Kev
Treating access violations as being something other than what they were intended to be.
Kev
And LMC doesn't consider correcting previous messages illegal, just negotiated outside 308
ralphm
Especially in the context of MUC where you can occupy someone's previous nick
Ge0rG
Kev: yes, and that negotiation can be done by means of a new feature var.
Ge0rG
What is the correct behavior if you receive a correction for a message that you don't know about?
Ge0rG
What is the correct behavior if you receive a correction for an older message?
APachhas joined
Kev
Undefined.
ralphm
And because we don't know it is weird.
larmahas left
larmahas joined
Ge0rG
So this _is_ the MUC of Message Editing, after all.
ralphm
Then again, the spec is deferred and would otherwise be experimental. Tough luck.
ralphm
We can just fix it properly
Nekithas left
Ge0rG
ralphm: so we don't need to bump the namespace at all!
adiaholichas left
ralphm
Arguably no. And if you are putting the thing inside an attach-to, it will behave slightly differently anyway for clients out there.
Ge0rG
Kev [11:34]:
> Treating access violations as being something other than what they were intended to be.
What would be your suggested approach?
larma
As I read it, there is no "invalid" LMC, it's just not an LMC if it's using an old or unknown message, so it would become a normal message, because there is no specification that says otherwise.
Ge0rG
larma: this is also the most sensible thing to do
ralphm
larma: I think we can agree we don't really know
kokonoehas left
Ge0rG
Unless silently hiding messages from the user is your fetish
ralphm
Have to drive now.
Ge0rG
Me too.
kokonoehas joined
Kev
larma: I think the right thing to do depends on the nature of the wrongness. If it's an older message than you have, displaying it fresh might be ok (although probably annotating it visually is better). If it's that you're trying to correct someone else's message or something, that seems worse.
Danielhas left
Danielhas joined
adiaholichas joined
Danielhas left
Danielhas joined
larma
Kev, there is no such thing as "trying to correct someone else's message" in LMC. As IDs are not required to be unique, the only sensible implementation is to understand the ID as referring to the last ID of the sending user (else I could stop you from correcting a message by sending a message with the same ID after yours).
Nekithas joined
larma
(sending user = full jid, in this context)
Danielhas left
Danielhas joined
adiaholichas left
ralphm
FWIW, I think introducing a feature where you*can* change the text of a message by someone else is a bad idea, even if that someone is a moderator.
Kev
Depends very much on context, I think.
Kev
It's not going to be a good thing for normal IM situations.
ralphm
Kev: do you have a good example?
pep.
fwiw, I know Mattermost allows it
Kev
ralphm: I'm thinking of bloggy type things.
pep.
Message editing of anybody by admins
goffi
kev: we have real blogging for bloggy things.
pep.
(not saying it's a good thing)
j.rhas left
j.rhas joined
Danielhas left
ralphm
I _might_ accept textual annotations, maybe with an instruction to forget the original body, but if you start allowing true edits, you can no longer rely on who said what.
Danielhas joined
Danielhas left
pep.
I agree I wouldn't want that either. I'm fine with retraction-like things though
Danielhas joined
Danielhas left
Mikaelahas left
Danielhas joined
Mikaelahas joined
ralphm
Right
ralphm
For blog things you can just use regular pubsub
Nekithas left
Danielhas left
Danielhas joined
Nekithas joined
Danielhas left
Danielhas joined
LNJhas joined
zachhas left
zachhas joined
lskdjfhas joined
sonnyhas joined
COM8has joined
eevvoorhas joined
linkmauvehas left
adiaholichas joined
Ge0rG
I was thinking of Web forum like functionality, where a Moderator can delete curse words, and the message gets annotated by "edited by $moderator"
!xsf_Martinhas left
pep.
That would also probably be pubsub?
pep.
Is this new attach thing also going to apply to pubsub?
zachhas left
zachhas joined
jubalhhas joined
COM8has left
linkmauvehas joined
pdurbinhas joined
APachhas left
APachhas joined
adiaholichas left
adiaholichas joined
COM8has joined
COM8has left
jcbrandhas left
jcbrandhas joined
COM8has joined
pdurbinhas left
j.rhas left
j.rhas joined
kokonoehas left
Kev
https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml updated, BTW. I feel this is probably sufficient that reactions could be framed in these terms and both make it to Experimental, although I don't pretend it's perfect.
marc_has left
jonas’
https://github.com/Kev/xeps/blob/fasten/inbox/fasten.xml#L88 I don’t particularly like that. Do you think there is a case where it is useful for a receiving entity to know *that* payloads outside of apply-to are used by apply-to, without knowing how the actual apply-to mechanism is supposed to work, i.e. in that case, without understanding what <edit/> means?
marc_has joined
Kev
Yes.
jonas’
can you give an example?
Kev
If you want MAM2 to be able to include the pertinent data in the grouped responses.
Kev
There's a note about it at the bottom.
jonas’
hmmm
jonas’
(I’m not good at reading uncompiled XEPs)
jonas’
MAM2 is an argument, I’m not sure if it’s a good one though.
jonas’
i.e. if it wouldn’t make more sense to make MAM2 return the full stanza in the general case, unless for features where it understands that only a partial stanza is needed
jonas’
thinking about what happens if a malfunctioning or malicious client omits the <external/> elements here
Kev
There are questions.
jonas’
as always
jonas’
not saying I would block on that basis, of course
Kev
I'm trying to avoid one of the unfortunate properties of LMC that it has horrible edge cases when you have additional payloads that aren't actually needed as replacements.
Kev
I think in answer to this question, a receiving client would treat it as malformed without the externals (or that it's trying to edit the origin stanza to have no payloads, possibly).
jonas’
right, so, this is only tangential, but I was thinking about how you expect a MAM response to look like. would those stanzas containing <apply-to/> be returned in a normal MAM query?
j.rhas left
Kev
Raw MAM1? Yes, probably.
jonas’
or would a client only get the summary on the stanza to which stuff was "fastened to"
jonas’
even MAM2
Kev
MAM2, I expect you to say what you want in the initial query somehow.
jonas’
hmm
jonas’
how would you handle the case where a client has already seen the stanza which was "fastened to", but now wants to catch up on new fastenings?
Kev
So if you're a MAM2 client that's asking for summaries with stanzas, you'd have the stanzas that were rolled into the summaries elided unless you ask for them specifically.
Kev
You mean a mid-sized client? Not a fat-client that does full-sync, nor a thin client that requests data when needed?
jonas’
I mean, even a fat-client could benefit a lot from summaries
jonas’
as a fat-client author, I’d be interested in that ;)
Kev
You'd like your fat-client to lose weight? :)
Alexhas left
jonas’
a bit of bandwidth-weight, yes
jonas’
if MAM can do a restructuring I’ll do myself anyways, I don’t see why I shouldn’t profit off that if it’s possible to do so :)
Zash
Summary, update UI, fetch actual data. Things look faster than they are 🙂
ralphm
The cases where we talked about summaries were reactions (debated here quite a bit) and simple polls (Summit). Neither of those cases are about 'external' elements like with LMC, so I'm not quite sure why we need to actuall explicitly mention them. Except maybe for sanity checks.
lumihas joined
moparisthebesthas joined
ralphm
Is this to somehow tell a client that it shouldn't render <body/> if it knows about fastening?
Kev
LMC is summaryish, though.
Kev
Or 'edit', at least.
Kev
To not confuse with current LMC.
ralphm
Oh, I actually thought it would be a case of replacing.
ralphm
(which I get that there isn't another fastening to be replaced)
Alexhas joined
Kev
It could be that any fastening that needs a <body> is a special type of summary that isn't really a summary, but just that the archive needs to return a full stanza containing the fastenings.
Kev
Big question is whether this is Experimental standard, I think.
Kev
If it is, I should submit it and move on to updating references to use it.
Kev
Or maybe get lunch.
moparisthebesthas left
moparisthebesthas joined
adiaholichas left
UsLhas joined
adiaholichas joined
jabberjockehas left
Chobbeshas joined
gavhas joined
adiaholichas left
Alexhas left
Alexhas joined
Alexhas left
adiaholichas joined
Alexhas joined
marc_has left
marc_has joined
debaclehas joined
COM8has left
debaclehas left
jabberjockehas joined
nycohas joined
nycohas left
ralphm
Kev: do you mean "should I submit this, or are we altering the existing experimental XEP by Sam"?
Kev
No.
Kev
I was asking whether anyone (mostly Council) felt this was not ready for Experimental, following on from the discussion in yesterday's meeting.
remkohas left
Zash
There is a way to find out
j.rhas joined
ralphm
Kev: from what I read, just submit it, and then later we can figure out what to do with competing specs
zachhas left
ralphm
It is not like we didn't have 3 pubsub specs
zachhas joined
ralphm
Also, you submitting it to the editor makes it possible for us to actually discuss it :-D
Nekithas left
ralphm
Because I have comments.
adiaholichas left
ralphm
and questions
Chobbeshas left
Nekithas joined
jabberjockehas left
ralphm
Also, I might not make it for the Board meeting.
jabberjockehas joined
Yagizahas joined
nycohas joined
nyco
hey
Guus
ola
Guus
ralphm Seve MattJ ?
Guus
uh-oh.
Guus
if this meeting is not going to happen, then I'd like to have an email vote on one of the topics that I scheduled for today.
Guus
The outcome can affect travel arrangements for people, so I'd like to get it out of the way
Guus
It regards flow email, the GSoC Mentor Summit stipend.
Guus
nyco did you get that?
nycois finishing a call
Guus
(he cc'ed me, so I definitely got it, unsure if the reset of board did).
adiaholichas joined
Guus
In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs.
nyco
yes, let's discuss that
Guus
Well, it's just you and me in this meeting, so we don't have quorum.
MattJ
Hey
Guus
but I'd like to resolve this, so that people can make arrangements.
Guus
ah, there's Quorum 🙂
Guusbangs gavel
Guus
0. Role call / agenda
Sevewaves
Guus
I've seen MattJ and Nyco, Seve starts typing now (hi!), Ralph mentions he might be late/missing.
nyco
_o/
Guus
As usual, the agenda is driven by Trello
Guus
https://trello.com/b/Dn6IQOu0/board-meetings
Guus
does anyone want to add something to the agenda for this meeting?
Guus
I'm taking that as a 'no'.
Guus
on to the fun part:
Guus
1. Confirm minute taker
Guus
Who?
Daniel
I can do minutes
Guus
Thanks Daniel!
Guus
2. Topics for decisions
Guus
2.1 GSoC Mentor summit stipend (Flow's mail)
Guus
I touched on this before the meeting started. Did all of board get Flow's mail?
MattJ
I did
Seve
I manage the mailing list, so I probably accepted it to go through but did not read it unfortunately (yet)
Guus
(I'm unsure if that works, mailinglist permission wise)
Guus
ok, great. Thanks Seve (for accepting it, not for not reading it 😉 )
Chobbeshas joined
Guus
Can you read it now? If at all possible, I'd like to resolve this in this meeting, as it can affect travel arrangements.
moparisthebesthas left
Guus
To repeat what I typed a short while ago:> In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs.✎
Guus
To repeat what I typed a short while ago:
> In short, Flow writes that we have 3 mentors that will visit the GSoC mentor summit. In other years, we'd have two. Flow asks if XSF is willing to reimburse the travel costs of all three mentors (as opposed to only the regular 2). He mentions that travel costs will be relatively low (mentors are largely in the same country as where the event venue is), and that the Google stipend that the XSF received will cover the costs. ✏
moparisthebesthas joined
flow
I see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW.
Guus
You asked, so i'm putting it to board 🙂
adiaholichas left
adiaholichas joined
Guus
I have no issue with reimbursing the travel costs for all mentors, provided that the total remains at or under the stipend we got from Google.
Guus
(i'd not mind paying slightly more, to be perfectly clear - but as that doesn't appear to be needed anyway, let's not discuss that)
MattJ
I'm in favour
nyco
sorry... I'm back
nycois reading
Seve
I'm done
Seve
Yes, makes perfect sense to me
Seve
I mean, I'm also on the "ok" side
Guus
Let me put it to a vote then: I'l motion that the XSF offers to reimbursre travelling costs for all three GSoC mentors of this year, to attend the GSoC Mentor summit, provided that the total costs are not more than the stipend that the XSF received from Google."
Guus
+1
MattJ
+1
Seve
+1
nyco
> I see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW.
I see lots of reasons why we should reimburse! :)
nyco
double negative sucks! :)
Seve
Haha
Guus
+1 then, nyco ? 🙂
nyco
+1
Guus
motion passed.
nycohas finished reading
Guus
flow can you make sure the mentors are aware of this?
Guus
Moving on...
Guus
2.2 Invite & Provide stipend for GSoC students to visit the XSF Summit
flow
Guus, will do
nyco
the coma is important here
Guus
we started doing this in 2017, I think: we offered a 150 euro stipend for the that-year student to visit the XSF summit.
nyco
and Thx Daniel for the minutes! :)
Guus
in 2017, I wrote this invitation to the three students we had that year:
> the XSF offers to each of you a reimbursement of up to 150 euro for costs that you have in relation to them if you would like to attend either (or both) of these events. This offer could, for instance, be used to cover some of your travelling or hotel expenses.
Guus
I'd like to offer the same thing to this years students.
Guus
The rationale being the same is then: as the XSF, we should try to attract new people to get involved with XMPP. These students are perfect candidates for that.
Guus
(the events mentioned in the text that I quotes are the XSF Summit and FOSDEM).
Guus
Thoughts?
Seve
I think it has been very positive thing to do, hasn'it it?
nyco
it was, at least for me
Guus
I'm unsure if we had students this year (I think we did offer, but I'm unsure if someone took it up)
MattJ
Guus, I'm definitely in favour of offering to this year's students
Guus
but I was very happy to see Paul (now a member) and Pawel (continues to be an XMPP contributor to the Ignite Realtime community) the year before!
Guus
Ok, let me put this to a vote then
nyco
yes, please
Guus
I'm motioning that the XSF offers a 150 euro reimbursement to each of this years GSoC students, to be used by them to cover any costs associated to them visiting the XSF Summit and / or Fosdem in early 2020.
nyco
+1
Seve
+1
nyco
not "or", but "and" in "Summit and FOSDEM"
MattJ
+1
Guus
I don't want to make them attend both, if they can't
MattJ
"and/or", a great construction
Guus
if they're going to show up for either, that'd be a win
Guus
and they'd likely show up in both.
Guus
nyco, can you accept "and/or", or do you insist on "and"?
mray asked for a list of possible badge combinations, which I compiled for him. I left the list in the trello item, assuming that Ralph would forward it
Guus
I'm unsure if anything happened beyond that.
Guus
I'll take this up with Ralph after the meeting.
Guus
I don't think there's more to add to that now, is there?
Seve
I don't think so
Guus
3.2 Review of Roadmap page
Guus
This one is Ralphs too. Let's wait for him to give feedback on this.
Guus
4 Items for discussion
adiaholichas joined
Guus
4.1 GSoC '19 has ended - do we want to evaluate?
Chobbeshas joined
nyco
evaluate what and how?
pep.
I'm open to discussion re gsoc
Guus
At the very least, I'd like to celebrate successes, if there were any.
nyco
celebrate anyway
nyco
get feedback from participants: student and mentors
that would be nice
pep.
Yes! Poezio got MAM support (a big chunk of it, still some bits being refactored here and there)
Guus
also, I'd like to discuss the process - especially as this year was the first time that flow took the lead in things.
MattJ
I'd like to thank flow for everything, things went very smoothly :)
nyco
yeah, thx flow!
pep.
Indeed, thanks
Guus
I'm thinking flow is doing other things. I'd like to ask him if he feels the need to discuss things, and if not, at least share a short summary of this years involvement.
Kev
I think we usually try to do a blog post about the summer.
Guus
That's not the worst idea.
Seve
That would be perfect thing to also mention on the newsletter
nyco
content: good
nyco
each participant could do a blog post, even a small one is better than nothing
Guus
students have been blogging weekly
nyco
yes, from them I would expect some kind of summary/synthesis
Guus
(but we failed to include that on our blog)
nyco
we mentionned these blog posts briefly on the newsletter
Guus
nyco, do you want to take this up with Flow, with our commsteam hat on?
nyco
why not
Guus
I don't know why not 🙂
Guus
but I thought it'd be polite to ask.
Guus
we're running over time. I'd like to conclude the meeting.
Guus
5. AOB
Guus
anyone?
Seve
None here
nyco
nope
MattJ
None here
COM8has joined
Seve
Apart from: Great to have things done :D
Guus
6 Time / date of next
nyco
yep, feels good
Guus
I can't make it next week, but don't let that stop you.
Guus
+1W
MattJ
Next week wfm
Guusbangs the gavel
nyco
thx all!
Seve
Awesome, thank you very much all, special thanks to Guus for chairing and Daniel for volunteering with the minutes :)
nyco
thanks to Seve for thanking everyone! :)
Seve
:D
jabberjockehas left
COM8has left
Chobbeshas left
eevvoorhas left
Guus
I like how ralphm is not here for just one, and the rest of us immediately spend all of the money that we have. 😉✎
Guus
I like how ralphm is not here for just once, and the rest of us immediately spend all of the money that we have. 😉 ✏
pep.
Is it possible to query the XSF (financial) accounts?
Guus
pep. I was kidding, we have plenty of cash to cover this
adiaholichas left
pep.
this?
andyhas left
zachhas left
Guus
"this" is "the spendings that we committed to in todays board meeting"
pep.
Because if it's possible I'd like to at least propose to our student in India as well, if he's interested. What has been voted today is great, but only covers transportation for people close enough
Guus
Peter, the Treasurer, actually keeps board up-to-date with the state of the financials.
Guus
so there's no worry there.
pep.
I'm not worried, I'm just interested to know. We don't seem to spend much money apart from that one diner once a year (why??)
pep.
So either we don't have money, which I doubt, or it's dormant
Guus
pep. although I'm sympathetic, it might be difficult to make a judgement that's fair here.
pep.
Depends how you define fair :P
Guus
well, exactly. That differs for everyone.
Guus
pep. I propose that you make a specific proposal and put that to board.
Andrew Nenakhovhas joined
Guus
The amount of money in the bank account has been pretty stable.
pep.
With the sponsors we have?
Guus
We got some new ones this year, but I'm not sure if we have more spendings.
Guus
I'm actually not sure if I can elaborate - I don't see why not, but I don't want to run my mouth 🙂
pep.
I'm curious why all this is private tbh
Guus
I'm not sure if it is
Guus
but I"m not sure if it is not 🙂
pep.
k
Guus
I'll ask Peter.
Andrew Nenakhovhas left
APachhas left
davidhas left
Guus
pep. i've sent off a quick email. I'll keep you in the loop if I remember to do that - feel free to ping me again about this.
pep.
thanks
Guus
no problem
zachhas joined
Kev
I've seen the balance of the accounts before, so I don't think it can be privileged.
Guus
I'll ask Peter - maybe we can properly publish something for everyone to see
Guus
and get what we can more in the open.
pep.
That'd be great :)
kokonoehas joined
APachhas joined
Guus
I'm guessing that things like this just died down a little, with lack of interest.
Guus
but that there's no reason to actually keep things confidential.
flow
There was a time where the XSF financials where regulary blogged about
Guus
But like I said, I'd like to check that.
davidhas joined
Daniel
Does anyone remember the order of magnitude we are talking about here?
Daniel
Because I have no clue
flow
and thanks for your gsoc feedback, much appreciated :)
Guus
low to medium five digits, iirc
Daniel
Guus: thanks
kokonoehas left
Kev
Last I remember was the sort of $15-$25k IIRC, but it was years ago.
winfriedhas left
winfriedhas joined
jabberjockehas joined
kokonoehas joined
Nekithas left
kokonoehas left
Nekithas joined
andyhas joined
kokonoehas joined
kokonoehas left
kokonoehas joined
kokonoehas left
kokonoehas joined
Chobbeshas joined
kokonoehas left
kokonoehas joined
adiaholichas joined
pdurbinhas joined
adiaholichas left
Zash
dwd, jcbrand, in XEP-0402 boomarks 2 there is no mention of how PEP nodes will likely default to max items = 1, which you probably wanna do something about
eevvoorhas joined
dwd
Zash, Give the XEP its full name, at least.
Zash
I'm going to have to write a bot that expands XEP names at some point
> I'm going to have to write a bot that expands XEP names at some point
pep.
does it?
wurstsalat
I think it did at some point
Daniel
na
Daniel
we just have smart people who know the xeps by heard
Kev
At Isode we've got a bot in the (XMPP) chat rooms that just injects XEP details when they get mentioned, based on my old sleekbot stuff updated for Sluift-based stuff.
adiaholichas left
adiaholichas joined
Zash
But does it use attaching or references or fasten?
Kev
It should use references, which will use fasten once I update it. But currently it doesn't, no.
kokonoehas left
APachhas left
APachhas joined
Chobbeshas left
jubalhhas left
kokonoehas joined
eevvoorhas joined
Chobbeshas joined
Wojtekhas joined
Ge0rG
Kev: it should also attach the references to the original.
Kev
Yes.
Ge0rG
I have a client that will hotlink XEP-####
jcbrandhas left
Wojtekhas left
zachhas left
lovetoxhas joined
kokonoehas left
kokonoehas joined
adiaholichas left
zachhas joined
eevvoorhas left
adiaholichas joined
COM8has left
archas left
archas joined
davidhas left
davidhas joined
andyhas left
andyhas joined
winfriedhas left
Syndacehas left
Syndacehas joined
winfriedhas joined
winfriedhas left
winfriedhas joined
moparisthebesthas left
j.rhas left
goffihas left
j.rhas joined
marc_has left
archas left
archas joined
archas left
archas joined
COM8has joined
COM8has left
pdurbinhas joined
moparisthebesthas joined
Dele (Mobile)has left
Steve Killehas left
Steve Killehas joined
Dele (Mobile)has joined
archas left
archas joined
pdurbinhas left
Dele (Mobile)has left
Dele (Mobile)has joined
Dele (Mobile)has left
Dele (Mobile)has joined
Chobbeshas left
Chobbeshas joined
Chobbeshas left
Chobbeshas joined
remkohas joined
winfriedhas left
winfriedhas joined
linkmauvehas left
linkmauvehas joined
moparisthebesthas left
Nekithas left
winfriedhas left
winfriedhas joined
adiaholichas left
jabberjockehas left
adiaholichas joined
Danielhas left
Yagizahas left
Danielhas joined
zachhas left
adiaholichas left
Danielhas left
zachhas joined
Danielhas joined
APachhas left
sonnyhas left
moparisthebesthas joined
j.rhas left
j.rhas joined
APachhas joined
adiaholichas joined
adiaholichas left
remkohas left
Dele (Mobile)has left
APachhas left
pdurbinhas joined
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
goffihas left
goffihas joined
lovetox
ok i googled "fasten"
lovetox
was this only used because Attaching was already used?
pep.
never heard of "fasten your seatbelt"? :P
pep.
I guess so
lovetox
yeah actually thats the only situation i heard that ever
lovetox
but yeah forgot about that, now that you say it
moparisthebest
call it Attareferastench
moparisthebest
compromise
pdurbinhas left
Nekithas joined
remkohas joined
mr.fisterhas joined
jonas’
I’m also not convinced this is a particularly great name
jonas’
or terminology
jabberjockehas joined
zachhas left
zachhas joined
remkohas left
eevvoorhas joined
j.rhas left
Ge0rG
I'm sure we can get rid of Attaching and reuse the name