XSF Discussion - 2018-12-19

Off-topic but will interest some of you: JMAP is a modern standard for email clients to connect to mail stores. It therefore primarily replaces IMAP + SMTP submission. It does not replace MTA-to-MTA SMTP transmission.

https://jmap.io

Nyeh!

The proposed standard is in "Last Call" : https://datatracker.ietf.org/doc/draft-ietf-jmap-core/

can we rm -rf it

We don't take kindly to JSON-HTTP APIs here

Seems like "modern" is synonym for http/json really.

Oh no, my plans for modernxmpp have been revealed!

Is it? That was like that even in 2012

That's not very modern

https://news.ycombinator.com/item?id=18715965#18716402

MattJ, Guus, https://trello.com/c/jruUmUzl/321-process-violation-xep-0412 is this the right place for that card? where is your "inbox"?

jonas’: that's it.

re buttons: I’m thinking +1, but with a threat that I’m blocking LC if this diverges too much into a XEP-0004 clone. any opinions?

is this a nasty thing to do?

or even a sensible thing?

jonas’, it's a sensible thing to do, no?

If you're happy with it as-is, approve it

If you're not happy with it later, don't approve it

I’d not say *happy*

Delighted then :)

jonas’: maybe it would be good to have the discussion of the protocol first, and the threats later?

IMHO, it would be great if somebody knowledgeable about XEP-0004 would provide a strawman proto-XEP for Data Form Buttons

hm

jonas’: there! you are doing it again!

I started that (and IIRC Zash did too), but in my case because I wanted more options than just buttons, and couldn’t reach something I’d enjoy.

oops I did it agaiiiin *singing*

jonas’: so the ’ is for spears?

no

Ge0rG, I see your point on the competing proposals, but we definitely need XEP-0004 extensions before

Shall I submit the dataforms buttons thing I wrote?

Zash: yes please.

Seems I don't have it on this machine

Zash: actually, you should have submitted it side-by-side with the Simple Buttons, just to scare us into accepting the latter.

Heh

heh

Anyways: http://cerdale.zash.se/upload/lhqGHZ7NyEuQw5Px/xform-buttons.md

Don't have the markdown conversion code here either

*https://

Connecting to cerdale.zash.se (cerdale.zash.se)|2a00:66c0:7:1::cd1e|:80... failed: Connection refused. Connecting to cerdale.zash.se (cerdale.zash.se)|77.110.10.20|:80... failed: Connection refused.

So sad.

https://cerdale.zash.se/upload/lhqGHZ7NyEuQw5Px/xform-buttons.md

https://op-co.de/tmp/xform-buttons.html there, I rendered it for you

Hey, now that everything supports HSTS and HSTS preload, I could probably stop listening on port 80.

Zash, you should add HSTS preload to zash.se.

Zash: it's not scary enough.

Ge0rG, why would it be scary?

Link Mauve: XEP-0004 is scary..

It’s not.

it is

I mean, it's something that can be immediately discovered as scary, as opposed to MUC, which you need a decade to appreciate all the pitfalls of.

it is a weird mix of interactive forms, m2m protocol and overly generic search result reporting

It’s a bit under-specified, but it’s far from scary, even after ten years of working with it.

all while it is nearly unextensible in a way which doesn’t break existing implementations

jonas’, “search” result?

that reporting stuff

which re-uses some parts of the data form wire format in awkward ways

I tend to -0 Buttons because of: - no i18n for the response, leading to surprising results for the user (you press "Ja" and it emits "yes") - the obvious overlap with ad-hoc data command forms

Ge0rG, Ad-hoc data forms as in XEP-0050?

Zash, did you also have a version doing ad-hoc, btw?

Link Mauve: no

jonas’, yeah.

We were looking at something that fills roughly the same role as Facebook Message Templates: https://developers.facebook.com/docs/messenger-platform/send-messages/templates/

Where besides buttons, you also have other UI elements that you can describe semantically, like image carousels.

XEP-0004 isn't _really_ the most ideal for this kind of use case.

Buttons doen't have any of those except for buttons, and those are half-i18ned

We haven't gone as far as defining an XML format for it yet, though.

ralphm, I'm currently working on similar (also mapping Facebook to XMPP), buttons will be a part of that

Ge0rG: sure, just giving some context

MattJ: interesting!

ralphm: I like the comparison to the facebook thing, BTW. I'm sure they invested heeavily into MVPing it

I'd love to see buttons and polls actually.

Problem with XEP-0004 is that all interactions are around, well, submitting a form.

That's not the same as what Facebook-like templates do. There, you define an action for a specific button, taking some context into consideration.

But yeah, polls is another such thing.

ralphm, though it’s possible to map the selection of a button from a set of buttons to list-single

list-single-actually-a-button

jonas’: the problem is generally that you want a set of (hidden) fields to send along with such an action. So it might be that one button is like submitting a form, but the 'template' itself isn't one.

ralphm, you can have multiple forms

in a single message

(playing devil’s advocate here, I’m not convinced that XEP-0004 as-is is the right thing either)

jonas’: yes, sure, forms could be part of the presentation, but then you need some container format that is basically your (semantic) presentation of the whole thing.

probably

I'm not convinced that the generic nature of XEP-0004 brings something to the table for this use case, but maybe it does.

All of this really sounds like 0050.

With extended 0004.

except that '50 can’t have message context

(again, as-is)

And maybe media sharing and maybe other things.

ralphm: don't those things end up being the same if the action is defined by the original sender of the form?

Ge0rG: well, maybe. The idea of XEP-0004 is that you can generically display any such form, without the client necessarily knowing about the business logic or meaning of fields.

ralphm: so if we had 0004 with additional buttons and label i18n, we would have a superset of Buttons, Polls etc?

Maybe also with a specified way to convey this in regular messages?

I think that it is quite possible to do something similar to Facebook templates for XMPP, but not sure that using XEP-0004 of the basis of that format is the right approach. Clicking a button might trigger submitting a XEP-0004 form, similar to XEP-0050, sure.

I agree that it does sound like 0050. Maybe there can be some work done to have it work with messages?

(recently I’ve been thinking that we should replace messages with IQs :-X)

jonas’: that idea was brought up before

jonas’: what is the motivation?

pep., helps us get rid of all the reciepts and delivery uncertainty

I.e. you'd probably like at least buttons, lists (with media), and maybe a caroussel of the former.

anyway, there are two things here: the presentational format (semantic, not dictating formatting), and processing actions from them.

jonas’: right I was also thinking about that when you mentioned IQs.

You only get one level of acks though with this. People will still want "read" markers

for more context, this is Facebook's view on buttons (that can be used in templates): https://developers.facebook.com/docs/messenger-platform/send-messages/buttons

pep.: yes, you IQ-send messages to your server and it does reliable delivery™

like with SMTP

on each step there is a defined handover; it’s not fire & forget

you have at-least-once semantics with SMTP, provided that required entities can be contacted within a timeout

(and don’t lie about taking responsibility for a message)

I'm all for reliable delivery™!

XMPP3 when?

XMPP 2000

XMPP 3000 Plus