danielwouldn’t neceassarily have been a reason for me to reject but i get where you are coming from
larmajonas’, thread allows multiple messages in a thread, business rules in that protoxep specifically says "Answers MUST NOT be be assumed to relate to any other messages than the referenced one."
jonas’larma, some rationale in the document would be appreciated before acceptance I think.
larmaI surely can write it down
jonas’to me it's not immediately obvious why <thread/> doesn't work here, since a reply could always fork off a fresh thread kind of
larmaonly if the initial message already had a thread id
danielit requires the og message to have a thread-id
jonas’ohh
jonas’meh
Ge0rGluckily, replies doesn't depend on the original to have an origin-id
danieli find the thread example not very fitting personally but i do see overlap with references and fastening
larmaOverlap in a sense of "points to a previous message in chat"
danieloverlap as in the authors intented this to be used for this
danieli think
jonas’oh, message attaching would be another one with overlap
jonas’so we're at five specs (if we count <thread/>) doing very similar things
larmaI don't agree they are "very similar", but I see what you mean. We probably need a section in the protoxep to tell them all apart
jonas’ok, I'm -0 on this, but this document desperately needs a Design Considerations section to explain why the other four standards are not an option to achieve the goal
jonas’-1, until there's a good explanation for why pubsub#type isn't an option.
Wojtekhas left
danieli don’t know enough about pubsub to make a good call on that
Ge0rGon-list
daniel+/- 0
larmaFYI, https://github.com/xsf/xeps/pull/986 has the explanation
Wojtekhas joined
jonas’should go into the document :)
danieldo you want to cast a vote larma?
danielor else I would like to move on
larmaon-list for now
daniellooking at the time
daniel5) Pending votes
danielEveryone but Jonas pending on XEP-0060: Release version 1.23.0
(https://github.com/xsf/xeps/pull/1126)
daniel-1 from me
danielshould go into 0004
danieland we should ask editor to cherry pick the editorial / non controversial bits from that PR
jonas’out of curiousity (I don't have any horses in that race), how would a '4 integration look like? sounds tricky to me, considering that '4 is Final.
larma-1 from me as well, although I'm not sure if 0004 is the right place either, but the proposal definitely shouldn't go as is
Ge0rG-1 with the PR as-is, maybe a better non-normative wording can be proposed if we fail to update 0004
danieljonas’, i think there has been some discussion on how that can still be done in 0004 in a compat way. but i also think a new xep (that modifies 0004) can be done
jonas’right
Ge0rGWow, we managed to run over time
danielyes. but we are mostly done I think
daniel6) Date of Next
jonas’+1w wfm
daniel+1w wfm
larma+1w
Ge0rG+1W
daniel7) AOB
either we don’t have any or I need to ask people if they are ok with extending the meeting by 10mins
danielany aob?
jonas’none
Wojtekhas left
larmano
Ge0rGnone
danielok. awesome. thank you everyone
daniel8) close
Ge0rGthanks daniel
jonas’Thanks daniel!
larmaThanks 🙂
KevBTW, as References Guy, I don't think References is a reason to block Replies, but agree that some explanation in Replies would be worthwhile.
ZashWe need a Venn diagram!
Kev(I do think references would work fine for the use case, but references being stuck (currently?) on URIs makes it a bit unfortunate.)
KevI think the whole space would greatly benefit from someone with time and understanding trying to map out how all the things work together (and that's the kind of leadership Council's good for), and I think that having a bunch of different ways to reference stanzas is undesirable, but ... yeah.
Ge0rGIsn't that what Summits were good for, before 2020?
Ge0rGsearching the wiki for references yields https://wiki.xmpp.org/web/Georg%27s_Talk_on_Message_routing among other things.
KevSummits used to be good for sorting out the high level view, and moderately ok for motivating people to write things, yes. There is a bit of an issue with XEPs written in a hurry to support stuff that was happening/just happened at Summits and then wither on the vine (e.g. References).
Ge0rGI could try to allocate a few hours to write down the principal means we have to reference messages with their pros/cons and to collect an overview of which XEP does what. That's the sort of thing I like delving in, after all. Would wiki format be appropriate, or should I make it another "what's wrong in ..." presentation?