Ge0rGThere might also be some merit in having a structured mapping between XEPs and feature identities.
ralphmI am curious if including the disco section in every XEP actually triggers developers to make sure they handle the discovery bits while implementing.
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
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.
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)
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/ :)
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 :)
Danieljonas’: any ejabberd should do
jonas’I’m ready to write the aioxmpp code, and I’m ready to make Muclumbus support it
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
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
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)
Steve Killehas left
Steve Killehas joined
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
ralphmdwd: yes, indeed
Dele (Mobile)has 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?
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
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?
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 :)
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
Ge0rGThis is going to become the MIX of Message References.
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 :)
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
ralphmGe0rG: how would you introduce the new feature?
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
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"?
Ge0rGralphm: in the Carbons+MAM world, there is no way to know which features the receiving client will have.
Ge0rGralphm: so yes, if you allow editing older messages on the sending side, the receiving side is not guaranteed to display those as edits
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?
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.
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?
ralphmAnd because we don't know it is weird.
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
Ge0rGralphm: so we don't need to bump the namespace at all!
ralphmArguably no. And if you are putting the thing inside an attach-to, it will behave slightly differently anyway for clients out there.
> 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
Ge0rGUnless silently hiding messages from the user is your fetish
ralphmHave to drive now.
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.
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).
larma(sending user = full jid, in this context)
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)
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.
pep.I agree I wouldn't want that either. I'm fine with retraction-like things though
ralphmFor blog things you can just use regular pubsub
Ge0rGI was thinking of Web forum like functionality, where a Moderator can delete curse words, and the message gets annotated by "edited by $moderator"
pep.That would also probably be pubsub?
pep.Is this new attach thing also going to apply to pubsub?
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.
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?
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’(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’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?
KevRaw MAM1? Yes, probably.
jonas’or would a client only get the summary on the stanza to which stuff was "fastened to"
KevMAM2, I expect you to say what you want in the initial query somehow.
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? :)
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.
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)
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.
ralphmKev: do you mean "should I submit this, or are we altering the existing experimental XEP by Sam"?
KevI was asking whether anyone (mostly Council) felt this was not ready for Experimental, following on from the discussion in yesterday's meeting.
ZashThere is a way to find out
ralphmKev: from what I read, just submit it, and then later we can figure out what to do with competing specs
ralphmIt is not like we didn't have 3 pubsub specs
ralphmAlso, you submitting it to the editor makes it possible for us to actually discuss it :-D
ralphmBecause I have comments.
ralphmAlso, I might not make it for the Board meeting.
Guusralphm Seve MattJ ?
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).
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.
Guusbut I'd like to resolve this, so that people can make arrangements.
Guusah, there's Quorum 🙂
Guus0. Role call / agenda
GuusI've seen MattJ and Nyco, Seve starts typing now (hi!), Ralph mentions he might be late/missing.
GuusAs usual, the agenda is driven by Trello
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
DanielI can do minutes
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?
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 😉 )
GuusCan you read it now? If at all possible, I'd like to resolve this in this meeting, as it can affect travel arrangements.
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.
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 🙂
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
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."
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! :)
Guus+1 then, nyco ? 🙂
nycohas finished reading
Guusflow can you make sure the mentors are aware of this?
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).
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
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.
nyconot "or", but "and" in "Summit and FOSDEM"
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
Guus4.1 GSoC '19 has ended - do we want to evaluate?
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.
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!
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
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?
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.
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.
MattJNext week wfm
Guusbangs the gavel
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! :)
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
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 🙂
GuusI'll ask Peter.
Andrew Nenakhovhas 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.
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 :)
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.
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
KevLast I remember was the sort of $15-$25k IIRC, but it was years ago.
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
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