XSF Discussion - 2017-12-04

I wonder if it would be a bad idea to ban html-only mails on standards@. It breaks display of quoting badly on text-only MUAs

markup discussions \o/

we haven’t had any for over a week

meta-markup.

or markup-meta?

I'm actually catching up the Styling thread from three weeks ago.

ah, so maybe using html-only there was an act of irony? :)

So far, the html-only mails I've read didn't contribute anything positive to the discussion. If it wasn't for my Council hat, I'd have blacklisted them already.

I'm actually glad that we are getting XEPs that define the visual format of things.

yeah, this is very important now, when basic things are borked

jonasw, using the Nickname as source of coloring would have other issues, like when somebody else joins a room with the same nick they'll get the same color, suggesting to the user that they are the same

hey marc, any news from your XEP?

zinid: why don't you volunteer some time and actually improve the protocols, then? :P

Ge0rG, typical open-source nerd detected 🙂 If you don't have the feature: write it!

Tobias, we have that problem with anonymous MUCs in any case

while you can act like this (many do) you will end up with no users of your standards eventually

true..so maybe in that case they should be all colored the same?

Tobias, that’s what is specified now

great

zinid: I didn't think much about any namespace issues with the retry element. I guess I can move it around.

https://motherboard.vice.com/en_us/article/595zg5/sopranica-jmp-wom-cell-network-diy-anonymous seems to be xmpp based.

daniel, I'm concerned because ejabberd has validation mode now, and I don't know how to validate unknown elements or attributes

the mode is optional

zinid: yes I'll add it beneath the iq then. I just didn't think about validation. In fact this can probably cause issues in other implementations as well. (just due to a lack of a getExtension method for the error class)

right

"the web address in your Jabber ID will be different—for example, motherboard@jabber.ccc.de or motherboard@xmpp.jp." That made my eyes bleed.

Ge0rG: no not yet (XEP)

marc: I'd really like to tear it apa.. eh.. I mean.. provide some constructive feedback

Ge0rG: let me check if I have Git access at the moment

Guus: that's an interesting article about an interesting tech. I remember there was an announcement of the JMP service on one of our MLs two months ago or so

But I didn't realize it's more than just a VoIP bridging service.

Ge0rG: I kind of had the same experience

also: be nice to marc.

I'm interested in adhoc 3G infrastructure for a completely different project, but now I forgot the MUC JID :(

bookmarks! :D

Guus: I've stored it in PEP, but then it was gone after a server upgrade!!!!1!

oh no! you did a _server upgrade_ ?!

s/upgrade/restart/?

Guus: I did a _server_ _upgrade_!

Guus, we’ll be nice to marc :)

I see we're back to the markup fun :)

thanks Jonas :)

jonasw: I'm not sure whom you mean by "we"

(mIRC references are one step down from bash.org quotes, right? :) )

Guus: you may only swing the trout from mIRC32.exe

Guus: unless you have screenshots of connecting to this MUC from mIRC, I won't take any damage.

Ge0rG: although that does sound like fun, I really should stop procrastinating :)

So I found some references to jmp.chat on the archives, but only from Denver's "signature"

> https://motherboard.vice.com/en_us/article/595zg5/sopranica-jmp-wom-cell-network-diy-anonymous seems to be xmpp based. Are the Americans reinventing freifunk?

daniel: it rather looks like SIP and picocells

You can join discuss@conference.soprani.ca if interested on that

picocells as in 4G? are you allowed to run those in the US?

Ge0rG, https://git.zapb.de/xeps.git/log/?h=user_invite_public

Ge0rG, as I said, just the protocol examples

daniel: if you are a telco and have the frequencies, then yes.

ok. i'll put it into my not gonna happen box

Is anyone going to the Paris Open Source Summit this week? https://wiki.xmpp.org/web/POSS_2017

SouL: that's what I was looking for, thanks

> fatal: unable to access 'https://git.zapb.de/xeps.git/': server certificate verification failed. Meh.

Ge0rG, pluralis majestatis

or so? ;-)

jonasw: I didn't dare to suggest that. But it's probably better than personality disorder.

:P

no, you’ll also be nice to marc *waves hand*

Ge0rG: it works, it uses LE

Must be a problem on your side ;)

marc: did you forget to add the cross-signed "root" cert to the chain?

Chain of trust NOT ok (chain incomplete)

Ge0rG: not that I'm aware of. It works on all clients for me

marc: it's apparently not in the Root CA list on my old-ish Debian box

Ge0rG: oh you're right 😬

Remove the 's' for now then ;)

marc: https://git.zapb.de/xep.git/? 😀

marc: I'm not removing the _other_ s.

😀

You have to wait with your "feedback" then ;)

jonasw: I consider it nice to think through what another person suggests and to make constructive feedback. I also consider it nice to not steal people's time by adding large amounts of boilerplate text that simulates politeness, instead just jumping to the point. For reasons beyond my comprehension, people call me blunt and negativistic.

Haha

marc: the git:// URL is also a lie :(

daniel: oh, no 3G... "WOM is XMPP over chibiArduino (thin messaging on IEEE 802.15.4)"

Ge0rG: fixed

Sorry

marc: thanks very much :)

Meh. How do you build html from an xeps/inbox/ file?

Ge0rG, make build/inbox/foo.html

or make inbox-html to build them all

jonasw: ah, thanks. That actually makes sense

And once again, I forgot to sql-extract from my backup phone the self-messages I wrote on MIX. :sad:

zinid, FWIW, RFC 6120 schemas are incorrect, so I wonder how much pain you’ll be having with validation.

at least afaict, the schemas do not allow for application-defined-condition in the error element, despite the text explicitly allowing that

also, the text allows for the use of the "code" attribute for compatibility, but the schema does not

jonasw, I can leave with this and fix the validator accordingly

what I don't want is doing this constantly

you may also be in violation of RFC 6120, because servers must simply route traffic addressed to clients (independent of their understanding), but I don’t have a quote for that right now

yeah, and in another place the RFC says you MAY validate, go figure

I understand your general concern, but ignoring undefined attributes and elements is essentially how extensibility in XMPP works.

no

this is not how it should work, because there simply can be tag names collisions if we allow adding whatever anyone wants

no, that’s why we have namespaces

a namespace is defined in a single document

(roughly)

for what it's worth, people in here repeatedly repeat that "schema's in XEPs are not normative" - Best beware to depend on them to much.

what's the point in this namespace if anyone can extend it?

zinid, define "anyone"

Pretty sure our equivalent to the robustness principle is "ignore what you don't understand"

the author and maintainer of the namespace can.

jonasw, you or me for example, can I use <foo xmlns='jabber:client'> for my extension?

no

well, you can, but that’d be stupid and asking for trouble

and <retry xmlns='http:upload:0'>?

and nobody would approve of that

same

unless you’re doing this in context of a XEP-0363 update

but you can?

you = XSF

owning the namespace you must ✏

I don’t think that the XSF would approve of a XEP update to any XEP *but* XEP-0363 which extends the http:upload:0 namespace

Only the IETF can introduce elements and attributes in the jabber:client xmlns through a replacement RFC, I think.

so, that means XSF can add whatever they want, but not others?

zinid, sure, the XSF "owns" the urn:xmpp namespace. that’s the whole point of having a standards organization?

It's all in our heads anyways

well, of course it's up to you, but I won't change ejabberd validation style

as I disagree

Zash, namespaces exists only because people believe in them?

zinid, what would you prefer?

bumping namespace obviously

and if people stop believe the whole system will collapse?

daniel: pretty much

zinid, that’s insanity.

bumping the namespace is a major breakage

also, this is an experimental XEP

jonasw, then wait for major breakage and add it in that revision

don’t expect any type of stability in there

if this is an experimental xep I don't see a problem in bumping at all

unnecssary namespace bumps are a bunch of the reason why "basic" things like MAM are troublesome.

but what do you expect from experimental xep?

what I expect from any XEP: no namespace bumps for backwards compatible changes

what I expect: the protocol should be formally verified

we can debate to death, really

This touches on a comment made by Jonasw on list - it's probably not the best of ideas to apply a change when the XEP is in last-call.

Then we should write down that rule in xep1

yes, the rules are: 1) schemas are meaningless 2) the protocol cannot be formally verified 3) only XSF can add new elements within the same namespace

now, implement!

Flow: I don't mind clarifying that in XEP-0001, but perhaps we can also simply try to avoid this from occurring, and save the red tape.

As the author of the XEP is also on Council, I'm interested in how this plays out though :)

zinid: I don't understand why you would want to add new elements with the official namespace. Just use your own

daniel, not me, but I see this quite frequently among customer's code

Is there anything stopping them from using their own namespace besides lack of knowledge (that they should do this)

because they don't want to create a namespace with a single element, I think that's their logic

i see

but you can hardly blame the system or the xsf for that

I can use validator to prevent such behaviour among customers

which works ideally, they don't even create tickets 😛

It's only worth bumping the namespace when interop that wouldn't work without it will work with it.

I think it comes down to whether you see XML and XMLNS as a pragmatic solution to permissionless innovation, or as a stick with which to beat people.

Not that I'm biased here of course. ;-)

MattJ, jonasw: would you feel more comfortable if retry is a direct child of the iq?

daniel, NO

that violates RFC 6120

iq can only have one child

please don’t do that

what you’re doing now is fine with RFC 6120, albeit weird usage of the "condition"

daniel, do you have an objection to just using the error type for this information?

MattJ: yes. I want to know _when_ I can retry

This could be seconds or hours

daniel, hm, how would the server know when the client can retry?

Depending on implementation

quota cleanup cronjob something?

MattJ, Well. Errors can have two, actually. Sort of.

Could this not be in a custom element next to the error?

dwd, ?

jonasw: we are taking about quotas like only x MiB an hour

MattJ, Error + original request.

daniel, well, actually, you could in fact make this a child of <iq/>, but I would consider that abuse. normally an error IQ only returns the original data, if anything

I haven't looked at whatever this <retry> thing is closely enough yet

Jabber.at is doing this

a "application-specific condition element" ala retry-after t=x

daniel, FWIW, I’m fine-ish with this being a child of <error/>. I find it a bit weird, though. Maybe wrap it in a <quota-exceeded xmlns="http-upload"/> thing first? Then there would be an actual condition, with additional information on when to re-try. It also allows to re-use the <retry/> for other possible conditions (like <ebusy/> or so)

then i have to define every possible error condition instead of relying on normal errors + text

daniel, good point

It seems like this is a specific case though, not something that could be combined with every other error

I'm curious what's wrong with defining errors and not just dumping text

pep., you need to foresee every possible condition

Can you not extent it later?

pep., we already have a huge bunch of 'predefined' errors

pep., maybe first read up on the context; in this case, it’s about annotating errors with a time at which the client may re-try

jonasw, yeah I need to read stuff

jonasw, if anything i could wrap it in something like <temporal-error><retry/></temporal-error> (working title)

daniel, as I said, I’m fine-ish with <retry/> as child of error. it feels weird, but I’m fine-ish with that.

well, that’s not usefull at all, leave it as child of <retry/> in that case, because that’s realyl just saying "this is *really* a type='wait' error, no kidding" :)

I have a larger problem with making substantial changes after last call begun :/

<error type='wait'><resource-constraint/><text>You exceeded the quota, try again in an hour or so</text><retry-after stamp="YYYY-MM-DDTHH:MM:SSZ"/></error> ?

i disagree with that being a substantial change

daniel, in hindsight, it probably was. see the amount o fdiscussion it caused.

I also probably meant "non-editorial changes" instead of "substantial changes"

hmm, https://xmpp.org/community/mailing-lists.html, there's a members@ somewhere?

Also https://xmpp.org/about/xsf/members.html doesn't seem up-to-date, anybody knows since when? So I can PR (if I find out who's been accepted and who hasn't)

you’re automatically subscribed if you become a member afaik

Ok. Can you give me a header I can filter on? I usually use List-ID

pep., haven’t you been subscribed already?

List-Id: XSF Members <members.xmpp.org>

or wait, your election is still upcoming? I don’t konw

I have no email coming from members@

Maybe it's still not done yet, we'll see

pep., it’s not done yet

cool

it’s finalized on the 7th I think

2017-12-06 is the meeting

daniel would it be possible to see if we can figure out the usage of SIMS in Conversations https://github.com/siacs/Conversations/issues/2637 ?

What particular feature do you need edhelas?

basically that when Conversations upload a file it embed it using SIMS to the message, and not only OOB

this allow other clients like Movim to have a bit more metadata about the file and create a nice thumbnail

I think I've asked like three times (sorry, I promise to write it down this time) but what was lacking from SIMS that OOB has that conversations uses?

nothing

it was just there before

edhelas, mind giving me an full example of a message stanza you want me to create?

Is this going to be another one of those times where the better solution dies because an okayish method already existed?

edhelas, i would also implement this in gajim

that would be awesome

Zash: first come first served

but only for httpupload in short term

daniel I can if you want, maybe tonight, but basically everything is done here in Movim https://github.com/movim/moxl/blob/master/src/Moxl/Stanza/Message.php#L101

OOB/SIMS is on my list of "things to deprecate one of", so if everyone wants to go implement SIMS that would make things much easier…

I'm doing SIMS and OOB when publishing and only SIMS when receiving

edhelas, so you put the url in the body and then set no begin and end attributes in the reference?

and you ignore the XEP MUST implement Jingle File Transfer (XEP-0234)?

that's true, I'll put this begin and end tags

daniel

Jingle-FT in movim when? :-°

i think the xep means OR

i dont see a reason why we have to implement jingle AND httpupload

> This XEP delegates actual transport of the media data to one of the existing file-transfer XEPs. Thus a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234) [2] and HTTP File Upload (XEP-0363) [4].

lovetox, are you sure? the <file> element is even in the jingle namespace

for what ever reason

so how does it work if I want to embed a file that was just uploaded by HTTP Upload ?

the file is not in my machine, I just have some metadata and a URL

edhelas, you tell me. you wanted me to implement the XEP :-)

ah i think the xep just builds up on jingle file transfer negotiation

so you have to implement the negotiation part

That whole section doesn't make much sense to me, I think it just needs to be reworded.

but do not have to offer the actual jingle transport

instead you put in httpupload

daniel that's all valid questions :) thanks for raising them

you also need bob for thumbnails which i find very weird

i'm not gonna implement bob

so we need to upaded SIMS, do HTTP Upload AND/OR Jingle FT

has *anyone* ever implemented bob?

I do

weird

no edhelas this xep builds up on jingle FT

to do stickers sharing, the files are small enough to be shared using base64

that does not mean you have to provide a jingle transport like socks5 or whatever

well yes. but the counterpart has to be online

which doesn't go well with the 'stateless' premise of the xep

I know a few people were talking of a jingle component (so server-side), any discussion started on this already?

so we have to tackle again this "file sharing" discussion

edhelas, i mean I can totally implement what you are doing in that PHP script you linked earlier. that's like 10 minutes work

but i'm really not sure that has anything to do with implementing the XEP

yeah I understand

to br frank I'm using SIMS to pass the metadata of HTTP File Upload to the other JID, that's mostly it

edhelas, what meta data are you interested in? mime type and size mostly i would assume?

maybe file name

by the way I personally also regard resolution (width * height) as a nice to have because that would could allow me to allocate space for this in the UI. which this XEP is not doing.

yup, mime and size as well, I'm not trusting them 100% but they tells me if I need to resolve the HTTP HEADER if I'm interested to build an attachement block to the message

so for me SIMS is just not doing the right thing. because i would ignore vast parts of the XEP and couldn't even but some information in there I want to put in there

*put

sims is just not trying to be a better OOB

Sure.

thats why it reuses jingle stuff

It's doing something completely different

if we are improving OOB to add those tags I'd be happy

i dont think so edhelas

or at least i dont know how easy we can extend a xep years long in draft

and if its good

I don't understand what SIMS is trying to be if not a better OOB; I agree that the XEPs focus seems a bit off, but that's fixable

oob has a clear use case, and does it well, you can communicated a uri with a description

really SamWhited ?

you dont see what it trys to do beside adding metadata?

No, as far as I can tell it's a better OOB except that it focuses on file transfer for some reason

you can share a file with multiple connection points for the receiver

he can choose if he wants to request it via jingle

or httpupload

Right, and that's all just sharing some metadata about the file

or any other FT method invented in the future

And basically what OOB does except in a more general way

It's OOB but with arbitrary URIs and some other random metadata

what is the argument? you can add a shittone of stuff to OOB xep then its the same?

Can you? I don't see definitions for anything like eg. different resolutions of the same file or other things SIMS has

i think we going in circles

frist you tell that you dont understand what sims trys to do

now you tell me oob does not have definitions about file resolutions

neither has sims though?

It doesn't, and I don't see how these two things are related; you said that SIMS doesn't do the same thing as OOB, and if that's true I don't understand what it does differently. To me it seems like it's just an improved OOB.

daniel i think you can just add more file tags

with different images

I thought SIMS specifically had that? Maybe I need to read it again

within the same reference?

how do i match a source and a file then?

nah i think im confusing this

this was 0084 with different avatar sizes or

Ah yah, this one is just thumbnail. Regardless, it was just an example. "more metadata than OOB" was the point.

yeah ok, but whats bad about this?!

It's a pointer.

it tries to be more general and have more info then oob

not just a bit more, WAY more

I don't really care if we have more or less metadata, I just think we don't need two XEPs that do more or less the same thing

so thats what i asked you 4 minutes ago

18:07:50] ‎lovetox‎: what is the argument? you can add a shittone of stuff to OOB xep then its the same?

SamWhited: You are giving me the impression that we can never improve on things that already exist, since that would require overlaping protocols for some time.

oob is a easy small xep that lets you share a description and a uri

let it be what it is

yes. wouldn't touch oob. if anything we would create a new XEP that is a more streamlined 'here is an uri and here is some meta data'

or SIMS can move into that direction

I’d prefer the latter

SIMS seems like nice framework to extend

I agree

the MUST support Jingle-FT is weird though

I didn’t know about that, maybe ask Tobias what that is about?

jonasw: Why is that weird?

and the bob thumbnails are even more weird

Zash, Jingle-FT is a rather complex beast, isn’t it?

jonasw: If it's basically a pointer to a thing available over Jingle-FT?

it’s not necessarily Jingle-FT, or doesn’t necessarily need to be Jingle-FT

Jingle-FT and SIMS are completely orthogonal; SIMS isn't a pointer to a Jingle URI, it also lets you have a pointer to an HTTP Upload API, and as far as I can tell could also provide a pointer to "my proprietary thing" URI.

or BOB

expect that it says must support jingle ft

and it's at least unclear how to do thumbnails without bob

That seems like it either means "must support using the Jingle FT metadata XML" or "must usupport Jingle FT *or* something else" and it was just poorly worded, but I guess we'd have to ask Tobias

maybe post that to the list, daniel?

That and the paragraph after it confuse me though, so I suspect we just need section 5.1 reworded for clarity.

im sure tobias just wanted to reuse already definied tags in another xep

instead of reinventing the same tags under a new namespace

jonasw, no. i have bigger fish to fry to be honest. things I actually need for Conversations. not saying that i won't implement SIMS but let other people figure out the details

either way i think its no problem to make this jingle agnostic

daniel, but spark the discussion maybe?

jonasw, that's gonna get ignored anyway

gotta love your optimism

like the one about MAM or the problems I raised with jingle-ft

and those are things i actually care about

MAM is being addressed isn't it? I thought Kev and Matthew responded to that and said they'd get a revision out

Hmm? Not reading context, but a MAM update is <> close to the top of my stack.

👍

i will post the questions to the list :)

i care about sims :)

do we really need thumbnails?

what I'd also like to see is a way to embed URLs in general to messages

with the metadata i can display some placeholder

like many other messaging solutions are doing now

having a littke thumbnail, description, title (the client will have to resolve thoses)

edhelas, isn't that what references is doing?

edhelas thats what the end and begin is for

so you can embed it in a message

let me rephrase that :)

XEP-0372: reference just gives a pointer to an URI, without metadata

XEP-0066: OOB gives a pointer to a URL with just a description

no, it also tells you where in the text the reference is to be placed ✏

with beginn and end

XEP-0385: gives all the metadata, but doesn'yt fit well with my usage (URL only)

gf

you probably need a og extension to references

like sims but with og data

og ?

http://ogp.me/

which if you have that you don't need sims anymore to cover your usecase

because you can put all that into og

kind of yes

also if I could have one generic way to attach thoses things to XMPP messages and/or Pubsub publications (that are actually Atom items as well) that would be nice

rrr heroku apps and their lack of tls :(

Or people failing to set it up correctly

daniel is it something that you'd like to have in Conversations ? URL/file embeding ?

what do you mean?

https://a.slack-edge.com/66f9/img/api/cnn_embed.png

isn't that exatcly would you would og and references for?

you'd have a reference that spans the entire url in this case

and the og:tile, og:description and og:image

yup, but would you like to implement it in Conversations as well ?

in general yes. but i have the blocker not having stanza content encryption

and that's not going to be resolved any time soon tbh

it's easier for me at this point to generate that information on the receiving end

(opt in)

yes I understand

also ironically - generating the content on might have some privacy related down sides; but to properly circumvent this you'd have to mirror the image on the sender or else you will be at least leaking the image url

what is the standard URI format fur Pubsub nodes and items ?