XSF Discussion - 2019-09-05

There might also be some merit in having a structured mapping between XEPs and feature identities.

I am curious if including the disco section in every XEP actually triggers developers to make sure they handle the discovery bits while implementing.

dwd, why would you need to change XEP-0001 for that?

I'm going to assume that not including it would lead to nobody implementing disco bits.

I agree with Zash

Indeed

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.”

As it doesn't include any example protocol flow, this feels much easier to "miss" while scanning the spec.

+1

I mean I said this yesterday. But nobody reads xeps. Everyone just copy pastes samples

(also funny that it refers to the pre-disco protocol)

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

Zash: I'm not sure that xep60 and 45 would have been better w/o the disco bits

But I get the point...

I'm glad that for MIX we already have a split now.

> I'm going to assume that not including it would lead to nobody implementing disco bits. I think that way as well

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.

ralphm, \o/ :)

I wish the open source community would be more enthusiastic about MIX

Daniel, I am extremely enthusiastic

I need a server to play with though :)

jonas’: any ejabberd should do

I’m ready to write the aioxmpp code, and I’m ready to make Muclumbus support it

oh?

I totally missed that

Ask Holger if you don't want to install your own

they have docker images, I’m fine with that

was MIX support in the newsletter?

jonas’: not that _we_ are currently stuck at where to put the channels if not the roster

That part is not implemented in ejabberd because it's stupid

But normal join / sending messages works

Daniel, PEP-ish thing?

jonas’: yes. Probably

PEP with server-side side-effects seems like a great thing in general.

But someone needs to write down the syntax

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.

ralphm: yes. Full ack

ISTM I have something to do during my vacation in 2w :)

As an example, I don't think you /need/ roster integration from the get go.

jonas’: I mean really an exploratory implementation can be written on a weekend

Daniel, not with my weekends at the moment ;)

And that includes reading the xep

Anyway, I'm currently focussed on rich messaging and pointing to things. MIX might be my next focus.

Client side I mean

Daniel: yes. At VEON we also had a simple implementation relatively quickly. On the server side, too.

Yeah. I don't think it took zinid too long either

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

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.

(as opposed to the other way around)

jonas’, The schema for XEPs is in XEP-0001, hence that involvement.

ralphm, I had a working MIX-with-MUC-interface in a few days at Threads.

dwd, the schema is not normative, meheard

especially since it’s not validated, only the DTD is

dwd: yes, indeed

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.

Am I being dense?

(r than normal)

Kev, having them as siblings was intended for backward compatibility

so that we don’t have to change the core LMC wire format

Yeah, my feeling was that I have a preference for a sibling

Was it? That certainly was not what I thought we were discussing.

(and don’t have to duplicate that information)

that’s what I read from Ge0rGs gist

I thought we were discussing having the e.g. <body/> outside the <apply-to/>.

> - for E2EE and legacy Last Message Correction, an <attach-to> without a payload implies that the sibling elements need to be reviewed

I have those words in front of me.

I read the "legacy" part as "for backward compat", I may be wrong

But I think we got confused.

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.

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.

Kev, makes sense

Kev: but then we end up with the overengineered <look-outside-for element-name="body" namespace="jabber:client"/> element

Ge0rG: I think we end up with that whatever happens. Just whether it's going to live inside the LMC or apply-to element.

(I also don't think it's overengineered)

It's the obvious generic thing.

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 ??? ??? ✏

Parses it again?

ralphm: the MUC needs to LMC the attached message, obviously

Yes. The MUC will need to understand LMC for this to work.

(Yes was to Ralph)

Ah, that is a good point, yes

so #4 will be a message attached to two different messages, with different attaching semantics

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?

ralphm: yes

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.

You'd have a chain

ralphm: a tree

Kev: would an implicit unapply by applying something new work? With a limit of one application per JID and application type?

So we need stanza versioning :)

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.

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)

Kev: we are overengineering it

This is going to become the MIX of Message References.

Dude

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.

Let's not make it the MUC of Message References :)

Heh.

So let's say we do Message Edits by means of stanza versioning. What kind of wire format do you suggest?

Will it use Attach-To (in a kind of privileged manner, checking the sender JID), or will it use a new, orthogonal syntax?

The stanza versioning was half-said in jest.

(Although if we were starting again it's probably the right thing to do)

There are some aspects I hate about LMC, but they can be changed without touching the wire format

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.

ralphm: I argue that we just can introduce a new feature.

I still see some merit in allowing room admins to change a message, though.

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

Ge0rG: how would you introduce the new feature?

larma: good point, but read markers attach to the latest message

which is a dumb thing in a protocol that lacks any kind of message ordering.

(I'm speaking of MAM here)

larma: the semantics of markers already say you should squash them? A server should only have one?

ralphm: by "feature" I meant a new var in disco#info

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

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?

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)

I don't think you should do read markers for stanzas that attach to others at all

ralphm: did you just say "resource locking"?

Huh?

ralphm: in the Carbons+MAM world, there is no way to know which features the receiving client will have.

Yes indeed

ralphm: so yes, if you allow editing older messages on the sending side, the receiving side is not guaranteed to display those as edits

Exactly

I can only hope that no implementor is dumb enough to just drop the new messages.

That'd be disappointing

ralphm: but bumping the namespace isn't going to improve that in any sensible way.

this is BTW the part of LMC that I dislike the most.

Well, you'd at least see all the things?

ralphm: what things?

If a client doesn't know the new thing it will just display the body?

yes.

So you have 'double' messages

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.

That sounds quite wrong.

And judgemental

So you will have double messages if you do an "illegal" v1 LMC, or if you have a v2 Edit.

Treating access violations as being something other than what they were intended to be.

And LMC doesn't consider correcting previous messages illegal, just negotiated outside 308

Especially in the context of MUC where you can occupy someone's previous nick

Kev: yes, and that negotiation can be done by means of a new feature var.

What is the correct behavior if you receive a correction for a message that you don't know about?

What is the correct behavior if you receive a correction for an older message?

Undefined.

And because we don't know it is weird.

So this _is_ the MUC of Message Editing, after all.

Then again, the spec is deferred and would otherwise be experimental. Tough luck.

We can just fix it properly

ralphm: so we don't need to bump the namespace at all!

Arguably no. And if you are putting the thing inside an attach-to, it will behave slightly differently anyway for clients out there.

Kev [11:34]: > Treating access violations as being something other than what they were intended to be. What would be your suggested approach?

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.

larma: this is also the most sensible thing to do

larma: I think we can agree we don't really know

Unless silently hiding messages from the user is your fetish

Have to drive now.

Me too.

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.

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).

(sending user = full jid, in this context)

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.

Depends very much on context, I think.

It's not going to be a good thing for normal IM situations.

Kev: do you have a good example?

fwiw, I know Mattermost allows it

ralphm: I'm thinking of bloggy type things.

Message editing of anybody by admins

kev: we have real blogging for bloggy things.

(not saying it's a good thing)

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.

I agree I wouldn't want that either. I'm fine with retraction-like things though

Right

For blog things you can just use regular pubsub

I was thinking of Web forum like functionality, where a Moderator can delete curse words, and the message gets annotated by "edited by $moderator"

That would also probably be pubsub?

Is this new attach thing also going to apply to pubsub?

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.

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?

Yes.

can you give an example?

If you want MAM2 to be able to include the pertinent data in the grouped responses.

There's a note about it at the bottom.

hmmm

(I’m not good at reading uncompiled XEPs)

MAM2 is an argument, I’m not sure if it’s a good one though.

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

thinking about what happens if a malfunctioning or malicious client omits the <external/> elements here

There are questions.

as always

not saying I would block on that basis, of course

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.

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).

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?

Raw MAM1? Yes, probably.

or would a client only get the summary on the stanza to which stuff was "fastened to"

even MAM2

MAM2, I expect you to say what you want in the initial query somehow.

hmm

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?

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.

You mean a mid-sized client? Not a fat-client that does full-sync, nor a thin client that requests data when needed?

I mean, even a fat-client could benefit a lot from summaries

as a fat-client author, I’d be interested in that ;)

You'd like your fat-client to lose weight? :)

a bit of bandwidth-weight, yes

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 :)

Summary, update UI, fetch actual data. Things look faster than they are 🙂

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.

Is this to somehow tell a client that it shouldn't render <body/> if it knows about fastening?

LMC is summaryish, though.

Or 'edit', at least.

To not confuse with current LMC.

Oh, I actually thought it would be a case of replacing.

(which I get that there isn't another fastening to be replaced)

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.

Big question is whether this is Experimental standard, I think.

If it is, I should submit it and move on to updating references to use it.

Or maybe get lunch.

Kev: do you mean "should I submit this, or are we altering the existing experimental XEP by Sam"?

No.

I was asking whether anyone (mostly Council) felt this was not ready for Experimental, following on from the discussion in yesterday's meeting.

There is a way to find out

Kev: from what I read, just submit it, and then later we can figure out what to do with competing specs

It is not like we didn't have 3 pubsub specs

Also, you submitting it to the editor makes it possible for us to actually discuss it :-D

Because I have comments.

and questions

Also, I might not make it for the Board meeting.

hey

ola

ralphm Seve MattJ ?

uh-oh.

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.

The outcome can affect travel arrangements for people, so I'd like to get it out of the way

It regards flow email, the GSoC Mentor Summit stipend.

nyco did you get that?

(he cc'ed me, so I definitely got it, unsure if the reset of board did).

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.

yes, let's discuss that

Well, it's just you and me in this meeting, so we don't have quorum.

Hey

but I'd like to resolve this, so that people can make arrangements.

ah, there's Quorum 🙂

0. Role call / agenda

I've seen MattJ and Nyco, Seve starts typing now (hi!), Ralph mentions he might be late/missing.

_o/

As usual, the agenda is driven by Trello

https://trello.com/b/Dn6IQOu0/board-meetings

does anyone want to add something to the agenda for this meeting?

I'm taking that as a 'no'.

on to the fun part:

1. Confirm minute taker

Who?

I can do minutes

Thanks Daniel!

2. Topics for decisions

2.1 GSoC Mentor summit stipend (Flow's mail)

I touched on this before the meeting started. Did all of board get Flow's mail?

I did

I manage the mailing list, so I probably accepted it to go through but did not read it unfortunately (yet)

(I'm unsure if that works, mailinglist permission wise)

ok, great. Thanks Seve (for accepting it, not for not reading it 😉 )

Can you read it now? If at all possible, I'd like to resolve this in this meeting, as it can affect travel arrangements.

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. ✏

I see no reason why we shouldn't reimburse the travel costs for all three mentors FWIW.

You asked, so i'm putting it to board 🙂

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.

(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)

I'm in favour

sorry... I'm back

I'm done

Yes, makes perfect sense to me

I mean, I'm also on the "ok" side

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."

+1

+1

+1

> 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! :)

double negative sucks! :)

Haha

+1 then, nyco ? 🙂

+1

motion passed.

flow can you make sure the mentors are aware of this?

Moving on...

2.2 Invite & Provide stipend for GSoC students to visit the XSF Summit

Guus, will do

the coma is important here

we started doing this in 2017, I think: we offered a 150 euro stipend for the that-year student to visit the XSF summit.

and Thx Daniel for the minutes! :)

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.

I'd like to offer the same thing to this years students.

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.

(the events mentioned in the text that I quotes are the XSF Summit and FOSDEM).

Thoughts?

I think it has been very positive thing to do, hasn'it it?

it was, at least for me

I'm unsure if we had students this year (I think we did offer, but I'm unsure if someone took it up)

Guus, I'm definitely in favour of offering to this year's students

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!

Ok, let me put this to a vote then

yes, please

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.

+1

+1

not "or", but "and" in "Summit and FOSDEM"

+1

I don't want to make them attend both, if they can't

"and/or", a great construction

if they're going to show up for either, that'd be a win

and they'd likely show up in both.

nyco, can you accept "and/or", or do you insist on "and"?

I'd +1 that too, but i'd prefer "and/or".

Great!

just a joke, I voted +1

+1 for me too

motion passes.

2.3 News from the newsletter

nyco I'm guessing this is yours?

yep

just FYI

JC has done a great job on the newsletter

I wanted to give justice

(Our student (poezio) is in india btw)

https://trello-attachments.s3.amazonaws.com/5d6e5d8116c843171be2a368/1120x420/068b7f8cb081fb7b2487da4abd8e9643/Capture_d’écran_2019-09-03_à_14.32.52.png

justice given.

the growth is awesome

Thank you to you for taking over, nyco

card can be archived

That is just... great :D

Thank you for sharing!

yes

moving on

3 Commitments for week ahead

3.1 Contact mray to confirm chosen Badge design

this is a shared commitment for Ralph and me.

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

I'm unsure if anything happened beyond that.

I'll take this up with Ralph after the meeting.

I don't think there's more to add to that now, is there?

I don't think so

3.2 Review of Roadmap page

This one is Ralphs too. Let's wait for him to give feedback on this.

4 Items for discussion

4.1 GSoC '19 has ended - do we want to evaluate?

evaluate what and how?

I'm open to discussion re gsoc

At the very least, I'd like to celebrate successes, if there were any.

celebrate anyway

get feedback from participants: student and mentors that would be nice

Yes! Poezio got MAM support (a big chunk of it, still some bits being refactored here and there)

also, I'd like to discuss the process - especially as this year was the first time that flow took the lead in things.

I'd like to thank flow for everything, things went very smoothly :)

yeah, thx flow!

Indeed, thanks

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.

I think we usually try to do a blog post about the summer.

That's not the worst idea.

That would be perfect thing to also mention on the newsletter

content: good

each participant could do a blog post, even a small one is better than nothing

students have been blogging weekly

yes, from them I would expect some kind of summary/synthesis

(but we failed to include that on our blog)

we mentionned these blog posts briefly on the newsletter

nyco, do you want to take this up with Flow, with our commsteam hat on?

why not

I don't know why not 🙂

but I thought it'd be polite to ask.

we're running over time. I'd like to conclude the meeting.

5. AOB

anyone?

None here

nope

None here

Apart from: Great to have things done :D

6 Time / date of next

yep, feels good

I can't make it next week, but don't let that stop you.

+1W

Next week wfm

thx all!

Awesome, thank you very much all, special thanks to Guus for chairing and Daniel for volunteering with the minutes :)

thanks to Seve for thanking everyone! :)

:D

I like how ralphm is not here for just once, and the rest of us immediately spend all of the money that we have. 😉 ✏

Is it possible to query the XSF (financial) accounts?

pep. I was kidding, we have plenty of cash to cover this

this?

"this" is "the spendings that we committed to in todays board meeting"

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

Peter, the Treasurer, actually keeps board up-to-date with the state of the financials.

so there's no worry there.

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??)

So either we don't have money, which I doubt, or it's dormant

pep. although I'm sympathetic, it might be difficult to make a judgement that's fair here.

Depends how you define fair :P

well, exactly. That differs for everyone.

pep. I propose that you make a specific proposal and put that to board.

The amount of money in the bank account has been pretty stable.

With the sponsors we have?

We got some new ones this year, but I'm not sure if we have more spendings.

I'm actually not sure if I can elaborate - I don't see why not, but I don't want to run my mouth 🙂

I'm curious why all this is private tbh

I'm not sure if it is

but I"m not sure if it is not 🙂

k

I'll ask Peter.

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.

thanks

no problem

I've seen the balance of the accounts before, so I don't think it can be privileged.

I'll ask Peter - maybe we can properly publish something for everyone to see

and get what we can more in the open.

That'd be great :)

I'm guessing that things like this just died down a little, with lack of interest.

but that there's no reason to actually keep things confidential.

There was a time where the XSF financials where regulary blogged about

But like I said, I'd like to check that.

Does anyone remember the order of magnitude we are talking about here?

Because I have no clue

and thanks for your gsoc feedback, much appreciated :)

low to medium five digits, iirc

Guus: thanks

Last I remember was the sort of $15-$25k IIRC, but it was years ago.

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

Zash, Give the XEP its full name, at least.

I'm going to have to write a bot that expands XEP names at some point

dwd, but this time, it *is* serious!

Guus: let it rain

https://igniterealtime.org:443/httpfileupload/bfc8728a-f5fb-4e11-868e-b3771dd7f44a/GkQG0BZ0TAe1LslOiO7I5Q.jpg

ralphm: ok.

Plz it just stopped

Argh, I wanted to say: make it rain. Never mind.

make: *** No rule to make target 'it'. Stop.

bmake: don't know how to make it. Stop

Zash, doesn't the conversations muc have one?

> I'm going to have to write a bot that expands XEP names at some point

does it?

I think it did at some point

na

we just have smart people who know the xeps by heard

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.

But does it use attaching or references or fasten?

It should use references, which will use fasten once I update it. But currently it doesn't, no.

Kev: it should also attach the references to the original.

Yes.

I have a client that will hotlink XEP-####

ok i googled "fasten"

was this only used because Attaching was already used?

never heard of "fasten your seatbelt"? :P

I guess so

yeah actually thats the only situation i heard that ever

but yeah forgot about that, now that you say it

call it Attareferastench

compromise

I’m also not convinced this is a particularly great name

or terminology

I'm sure we can get rid of Attaching and reuse the name