Ge0rGThere 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
ralphmI 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?
ZashI'm going to assume that not including it would lead to nobody implementing disco bits.
jonas’I agree with Zash
ralphmIndeed
ralphmWhile 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.”
ralphmAs it doesn't include any example protocol flow, this feels much easier to "miss" while scanning the spec.
zachhas left
zachhas joined
jonas’+1
DanielI 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
ZashOn 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
DanielZash: I'm not sure that xep60 and 45 would have been better w/o the disco bits
DanielBut I get the point...
ralphmI'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
ralphmjonas’: 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
DanielI 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
Danieljonas’: 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
DanielAsk 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?
Danieljonas’: not that _we_ are currently stuck at where to put the channels if not the roster
DanielThat part is not implemented in ejabberd because it's stupid
DanielBut normal join / sending messages works
jonas’Daniel, PEP-ish thing?
Danieljonas’: yes. Probably
jonas’PEP with server-side side-effects seems like a great thing in general.
DanielBut someone needs to write down the syntax
ralphmDaniel: 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.
Danielralphm: yes. Full ack
jonas’ISTM I have something to do during my vacation in 2w :)
ralphmAs an example, I don't think you /need/ roster integration from the get go.
Danieljonas’: I mean really an exploratory implementation can be written on a weekend
jonas’Daniel, not with my weekends at the moment ;)
DanielAnd that includes reading the xep
ralphmAnyway, I'm currently focussed on rich messaging and pointing to things. MIX might be my next focus.
DanielClient side I mean
ralphmDaniel: yes. At VEON we also had a simple implementation relatively quickly. On the server side, too.
DanielYeah. I don't think it took zinid too long either
pdurbinhas left
DanielI 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
ralphmAnd 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
dwdjonas’, The schema for XEPs is in XEP-0001, hence that involvement.
dwdralphm, 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
ralphmdwd: 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
KevGe0rG / 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.
KevAm 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
ralphmYeah, my feeling was that I have a preference for a sibling
KevWas 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
KevI 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
KevI have those words in front of me.
jonas’I read the "legacy" part as "for backward compat", I may be wrong
KevBut I think we got confused.
KevI 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.
ralphmEspecially 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
Ge0rGKev: but then we end up with the overengineered <look-outside-for element-name="body" namespace="jabber:client"/> element
KevGe0rG: 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)
Ge0rGIt's the obvious generic thing.
Ge0rGBut what happens when:
1. I send a message to a MUC
2. the MUC attaches references
3. I LMC that message
4. the MUC ??? ???✎
Ge0rGBut 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 ??? ??? ✏
ralphmParses it again?
Nekithas left
Ge0rGralphm: the MUC needs to LMC the attached message, obviously
KevYes. The MUC will need to understand LMC for this to work.
Kev(Yes was to Ralph)
ralphmAh, that is a good point, yes
pdurbinhas joined
Ge0rGso #4 will be a message attached to two different messages, with different attaching semantics
ralphmIf 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
Ge0rGralphm: yes
KevI 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.
ralphmYou'd have a chain
Ge0rGralphm: a tree
Ge0rGKev: would an implicit unapply by applying something new work? With a limit of one application per JID and application type?
KevSo we need stanza versioning :)
moparisthebesthas left
KevI 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.
ralphmKev: 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)
Ge0rGKev: we are overengineering it
Nekithas joined
Ge0rGThis is going to become the MIX of Message References.
ralphmDude
KevI'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.
KevLet's not make it the MUC of Message References :)
Ge0rGHeh.
wurstsalathas left
wurstsalathas joined
pdurbinhas left
Yagizahas left
Ge0rGSo let's say we do Message Edits by means of stanza versioning. What kind of wire format do you suggest?
Ge0rGWill it use Attach-To (in a kind of privileged manner, checking the sender JID), or will it use a new, orthogonal syntax?
KevThe stanza versioning was half-said in jest.
Kev(Although if we were starting again it's probably the right thing to do)
Ge0rGThere are some aspects I hate about LMC, but they can be changed without touching the wire format
ralphmI'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.
Ge0rGralphm: I argue that we just can introduce a new feature.
Ge0rGI still see some merit in allowing room admins to change a message, though.
larmaI 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
ralphmGe0rG: how would you introduce the new feature?
alameyohas joined
Ge0rGlarma: good point, but read markers attach to the latest message
Ge0rGwhich is a dumb thing in a protocol that lacks any kind of message ordering.
Ge0rG(I'm speaking of MAM here)
ralphmlarma: the semantics of markers already say you should squash them? A server should only have one?
Ge0rGralphm: by "feature" I meant a new var in disco#info
Ge0rGI'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
ralphmGe0rG: 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?
larmaCurrent 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)
ralphmI don't think you should do read markers for stanzas that attach to others at all
Ge0rGralphm: did you just say "resource locking"?
marc_has left
marc_has joined
ralphmHuh?
Ge0rGralphm: in the Carbons+MAM world, there is no way to know which features the receiving client will have.
ralphmYes indeed
Ge0rGralphm: 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
ralphmExactly
Ge0rGI can only hope that no implementor is dumb enough to just drop the new messages.
ralphmThat'd be disappointing
Ge0rGralphm: but bumping the namespace isn't going to improve that in any sensible way.
Ge0rGthis is BTW the part of LMC that I dislike the most.
ralphmWell, you'd at least see all the things?
Ge0rGralphm: what things?
ralphmIf a client doesn't know the new thing it will just display the body?
Ge0rGyes.
ralphmSo you have 'double' messages
Ge0rGif a client supports LMC and considers an edit as illegal, it will also just display the body, unless the developer is a huge moron.
KevThat sounds quite wrong.
ralphmAnd judgemental
Ge0rGSo you will have double messages if you do an "illegal" v1 LMC, or if you have a v2 Edit.
KevTreating access violations as being something other than what they were intended to be.
ralphmEspecially in the context of MUC where you can occupy someone's previous nick
Ge0rGKev: yes, and that negotiation can be done by means of a new feature var.
Ge0rGWhat is the correct behavior if you receive a correction for a message that you don't know about?
Ge0rGWhat is the correct behavior if you receive a correction for an older message?
APachhas joined
KevUndefined.
ralphmAnd because we don't know it is weird.
larmahas left
larmahas joined
Ge0rGSo this _is_ the MUC of Message Editing, after all.
ralphmThen again, the spec is deferred and would otherwise be experimental. Tough luck.
ralphmWe can just fix it properly
Nekithas left
Ge0rGralphm: so we don't need to bump the namespace at all!
adiaholichas left
ralphmArguably no. And if you are putting the thing inside an attach-to, it will behave slightly differently anyway for clients out there.
Ge0rGKev [11:34]:
> Treating access violations as being something other than what they were intended to be.
What would be your suggested approach?
larmaAs 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.
Ge0rGlarma: this is also the most sensible thing to do
ralphmlarma: I think we can agree we don't really know
kokonoehas left
Ge0rGUnless silently hiding messages from the user is your fetish
ralphmHave to drive now.
Ge0rGMe too.
kokonoehas joined
Kevlarma: 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
larmaKev, 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
ralphmFWIW, 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.
KevDepends very much on context, I think.
KevIt's not going to be a good thing for normal IM situations.
ralphmKev: do you have a good example?
pep.fwiw, I know Mattermost allows it
Kevralphm: I'm thinking of bloggy type things.
pep.Message editing of anybody by admins
goffikev: we have real blogging for bloggy things.
pep.(not saying it's a good thing)
j.rhas left
j.rhas joined
Danielhas left
ralphmI _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
ralphmRight
ralphmFor 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
Ge0rGI 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
Kevhttps://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
KevYes.
jonas’can you give an example?
KevIf you want MAM2 to be able to include the pertinent data in the grouped responses.
KevThere'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
KevThere are questions.
jonas’as always
jonas’not saying I would block on that basis, of course
KevI'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.
KevI 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
KevRaw MAM1? Yes, probably.
jonas’or would a client only get the summary on the stanza to which stuff was "fastened to"
jonas’even MAM2
KevMAM2, 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?
KevSo 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.
KevYou 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 ;)
KevYou'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 :)
ZashSummary, update UI, fetch actual data. Things look faster than they are 🙂
ralphmThe 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
ralphmIs this to somehow tell a client that it shouldn't render <body/> if it knows about fastening?
KevLMC is summaryish, though.
KevOr 'edit', at least.
KevTo not confuse with current LMC.
ralphmOh, 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
KevIt 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.
KevBig question is whether this is Experimental standard, I think.
KevIf it is, I should submit it and move on to updating references to use it.
KevOr 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
ralphmKev: do you mean "should I submit this, or are we altering the existing experimental XEP by Sam"?
KevNo.
KevI was asking whether anyone (mostly Council) felt this was not ready for Experimental, following on from the discussion in yesterday's meeting.
remkohas left
ZashThere is a way to find out
j.rhas joined
ralphmKev: from what I read, just submit it, and then later we can figure out what to do with competing specs
zachhas left
ralphmIt is not like we didn't have 3 pubsub specs
zachhas joined
ralphmAlso, you submitting it to the editor makes it possible for us to actually discuss it :-D
Nekithas left
ralphmBecause I have comments.
adiaholichas left
ralphmand questions
Chobbeshas left
Nekithas joined
jabberjockehas left
ralphmAlso, I might not make it for the Board meeting.
jabberjockehas joined
Yagizahas joined
nycohas joined
nycohey
Guusola
Guusralphm Seve MattJ ?
Guusuh-oh.
Guusif 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.
GuusThe outcome can affect travel arrangements for people, so I'd like to get it out of the way
GuusIt regards flow email, the GSoC Mentor Summit stipend.
Guusnyco 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
GuusIn 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.
nycoyes, let's discuss that
GuusWell, it's just you and me in this meeting, so we don't have quorum.
MattJHey
Guusbut I'd like to resolve this, so that people can make arrangements.
Guusah, there's Quorum 🙂
Guusbangs gavel
Guus0. Role call / agenda
Sevewaves
GuusI've seen MattJ and Nyco, Seve starts typing now (hi!), Ralph mentions he might be late/missing.
nyco_o/
GuusAs usual, the agenda is driven by Trello
Guushttps://trello.com/b/Dn6IQOu0/board-meetings
Guusdoes anyone want to add something to the agenda for this meeting?
GuusI'm taking that as a 'no'.
Guuson to the fun part:
Guus1. Confirm minute taker
GuusWho?
DanielI can do minutes
GuusThanks Daniel!
Guus2. Topics for decisions
Guus2.1 GSoC Mentor summit stipend (Flow's mail)
GuusI touched on this before the meeting started. Did all of board get Flow's mail?
MattJI did
SeveI 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)
Guusok, great. Thanks Seve (for accepting it, not for not reading it 😉 )
Chobbeshas joined
GuusCan 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
GuusTo 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.✎
GuusTo 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
flowI see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW.
GuusYou asked, so i'm putting it to board 🙂
adiaholichas left
adiaholichas joined
GuusI 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)
MattJI'm in favour
nycosorry... I'm back
nycois reading
SeveI'm done
SeveYes, makes perfect sense to me
SeveI mean, I'm also on the "ok" side
GuusLet 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! :)
nycodouble negative sucks! :)
SeveHaha
Guus+1 then, nyco ? 🙂
nyco+1
Guusmotion passed.
nycohas finished reading
Guusflow can you make sure the mentors are aware of this?
GuusMoving on...
Guus2.2 Invite & Provide stipend for GSoC students to visit the XSF Summit
flowGuus, will do
nycothe coma is important here
Guuswe started doing this in 2017, I think: we offered a 150 euro stipend for the that-year student to visit the XSF summit.
nycoand Thx Daniel for the minutes! :)
Guusin 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.
GuusI'd like to offer the same thing to this years students.
GuusThe 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).
GuusThoughts?
SeveI think it has been very positive thing to do, hasn'it it?
nycoit was, at least for me
GuusI'm unsure if we had students this year (I think we did offer, but I'm unsure if someone took it up)
MattJGuus, I'm definitely in favour of offering to this year's students
Guusbut 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!
GuusOk, let me put this to a vote then
nycoyes, please
GuusI'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
nyconot "or", but "and" in "Summit and FOSDEM"
MattJ+1
GuusI don't want to make them attend both, if they can't
MattJ"and/or", a great construction
Guusif they're going to show up for either, that'd be a win
Guusand they'd likely show up in both.
Guusnyco, can you accept "and/or", or do you insist on "and"?
Guus3.1 Contact mray to confirm chosen Badge design
Guusthis is a shared commitment for Ralph and me.
Guusmray 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
GuusI'm unsure if anything happened beyond that.
GuusI'll take this up with Ralph after the meeting.
GuusI don't think there's more to add to that now, is there?
SeveI don't think so
Guus3.2 Review of Roadmap page
GuusThis one is Ralphs too. Let's wait for him to give feedback on this.
Guus4 Items for discussion
adiaholichas joined
Guus4.1 GSoC '19 has ended - do we want to evaluate?
Chobbeshas joined
nycoevaluate what and how?
pep.I'm open to discussion re gsoc
GuusAt the very least, I'd like to celebrate successes, if there were any.
nycocelebrate anyway
nycoget 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)
Guusalso, I'd like to discuss the process - especially as this year was the first time that flow took the lead in things.
MattJI'd like to thank flow for everything, things went very smoothly :)
nycoyeah, thx flow!
pep.Indeed, thanks
GuusI'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.
KevI think we usually try to do a blog post about the summer.
GuusThat's not the worst idea.
SeveThat would be perfect thing to also mention on the newsletter
nycocontent: good
nycoeach participant could do a blog post, even a small one is better than nothing
Guusstudents have been blogging weekly
nycoyes, from them I would expect some kind of summary/synthesis
Guus(but we failed to include that on our blog)
nycowe mentionned these blog posts briefly on the newsletter
Guusnyco, do you want to take this up with Flow, with our commsteam hat on?
nycowhy not
GuusI don't know why not 🙂
Guusbut I thought it'd be polite to ask.
Guuswe're running over time. I'd like to conclude the meeting.
Guus5. AOB
Guusanyone?
SeveNone here
nyconope
MattJNone here
COM8has joined
SeveApart from: Great to have things done :D
Guus6 Time / date of next
nycoyep, feels good
GuusI can't make it next week, but don't let that stop you.
Guus+1W
MattJNext week wfm
Guusbangs the gavel
nycothx all!
SeveAwesome, thank you very much all, special thanks to Guus for chairing and Daniel for volunteering with the minutes :)
nycothanks to Seve for thanking everyone! :)
Seve:D
jabberjockehas left
COM8has left
Chobbeshas left
eevvoorhas left
GuusI like how ralphm is not here for just one, and the rest of us immediately spend all of the money that we have. 😉✎
GuusI 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?
Guuspep. 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
GuusPeter, the Treasurer, actually keeps board up-to-date with the state of the financials.
Guusso 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
Guuspep. although I'm sympathetic, it might be difficult to make a judgement that's fair here.
pep.Depends how you define fair :P
Guuswell, exactly. That differs for everyone.
Guuspep. I propose that you make a specific proposal and put that to board.
Andrew Nenakhovhas joined
GuusThe amount of money in the bank account has been pretty stable.
pep.With the sponsors we have?
GuusWe got some new ones this year, but I'm not sure if we have more spendings.
GuusI'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
GuusI'm not sure if it is
Guusbut I"m not sure if it is not 🙂
pep.k
GuusI'll ask Peter.
Andrew Nenakhovhas left
APachhas left
davidhas left
Guuspep. 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
Guusno problem
zachhas joined
KevI've seen the balance of the accounts before, so I don't think it can be privileged.
GuusI'll ask Peter - maybe we can properly publish something for everyone to see
Guusand get what we can more in the open.
pep.That'd be great :)
kokonoehas joined
APachhas joined
GuusI'm guessing that things like this just died down a little, with lack of interest.
Guusbut that there's no reason to actually keep things confidential.
flowThere was a time where the XSF financials where regulary blogged about
GuusBut like I said, I'd like to check that.
davidhas joined
DanielDoes anyone remember the order of magnitude we are talking about here?
DanielBecause I have no clue
flowand thanks for your gsoc feedback, much appreciated :)
Guuslow to medium five digits, iirc
DanielGuus: thanks
kokonoehas left
KevLast 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
Zashdwd, 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
dwdZash, Give the XEP its full name, at least.
ZashI'm going to have to write a bot that expands XEP names at some point
ralphmArgh, I wanted to say: make it rain. Never mind.
Chobbeshas left
kokonoehas left
Chobbeshas joined
dwdmake: *** No rule to make target 'it'. Stop.
Zashbmake: don't know how to make it. Stop
adiaholichas left
kokonoehas joined
adiaholichas joined
wurstsalatZash, doesn't the conversations muc have one?
wurstsalat> I'm going to have to write a bot that expands XEP names at some point
pep.does it?
wurstsalatI think it did at some point
Danielna
Danielwe just have smart people who know the xeps by heard
KevAt 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
ZashBut does it use attaching or references or fasten?
KevIt 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
Ge0rGKev: it should also attach the references to the original.
KevYes.
Ge0rGI 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
lovetoxok i googled "fasten"
lovetoxwas this only used because Attaching was already used?
pep.never heard of "fasten your seatbelt"? :P
pep.I guess so
lovetoxyeah actually thats the only situation i heard that ever
lovetoxbut yeah forgot about that, now that you say it
moparisthebestcall it Attareferastench
moparisthebestcompromise
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
Ge0rGI'm sure we can get rid of Attaching and reuse the name
