XSF Discussion - 2017-12-04

  1. Ge0rG

    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

  2. jonasw

    markup discussions \o/

  3. jonasw

    we haven’t had any for over a week

  4. Ge0rG


  5. Ge0rG

    or markup-meta?

  6. Ge0rG

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

  7. jonasw

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

  8. Ge0rG

    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.

  9. Ge0rG

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

  10. zinid

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

  11. Tobias

    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

  12. Ge0rG

    hey marc, any news from your XEP?

  13. Ge0rG

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

  14. zinid

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

  15. jonasw

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

  16. zinid

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

  17. Tobias

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

  18. jonasw

    Tobias, that’s what is specified now

  19. Tobias


  20. daniel

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

  21. Guus

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

  22. zinid

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

  23. zinid

    the mode is optional

  24. daniel

    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)

  25. zinid


  26. Ge0rG

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

  27. marc

    Ge0rG: no not yet (XEP)

  28. Ge0rG

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

  29. marc

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

  30. Ge0rG

    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

  31. Ge0rG

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

  32. Guus

    Ge0rG: I kind of had the same experience

  33. Guus

    also: be nice to marc.

  34. Ge0rG

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

  35. Guus

    bookmarks! :D

  36. Ge0rG

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

  37. Guus

    oh no! you did a _server upgrade_ ?!

  38. jonasw


  39. Ge0rG

    Guus: I did a _server_ _upgrade_!

  40. jonasw

    Guus, we’ll be nice to marc :)

  41. Guus

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

  42. Guus

    thanks Jonas :)

  43. Ge0rG

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

  44. Guus takes out his trusty smelly trout and eyes Ge0rG...

  45. Guus

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

  46. Ge0rG

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

  47. Ge0rG

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

  48. Guus

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

  49. Ge0rG

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

  50. daniel

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

  51. Ge0rG

    daniel: it rather looks like SIP and picocells

  52. SouL

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

  53. daniel

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

  54. marc

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

  55. marc

    Ge0rG, as I said, just the protocol examples

  56. Ge0rG

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

  57. daniel

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

  58. Guus

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

  59. Ge0rG

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

  60. Ge0rG

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

  61. jonasw

    Ge0rG, pluralis majestatis

  62. jonasw

    or so? ;-)

  63. Ge0rG

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

  64. jonasw


  65. jonasw

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

  66. marc

    Ge0rG: it works, it uses LE

  67. marc

    Must be a problem on your side ;)

  68. Ge0rG

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

  69. Ge0rG

    Chain of trust NOT ok (chain incomplete)

  70. marc

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

  71. Ge0rG

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

  72. marc

    Ge0rG: oh you're right 😬

  73. marc

    Remove the 's' for now then ;)

  74. Ge0rG

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

  75. Ge0rG

    marc: I'm not removing the _other_ s.

  76. marc


  77. marc

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

  78. Ge0rG

    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.

  79. SouL


  80. Ge0rG

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

  81. Ge0rG

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

  82. marc

    Ge0rG: fixed

  83. marc


  84. Ge0rG

    marc: thanks very much :)

  85. Ge0rG

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

  86. jonasw

    Ge0rG, make build/inbox/foo.html

  87. jonasw

    or make inbox-html to build them all

  88. Ge0rG

    jonasw: ah, thanks. That actually makes sense

  89. Ge0rG

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

  90. jonasw

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

  91. jonasw

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

  92. jonasw

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

  93. zinid

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

  94. zinid

    what I don't want is doing this constantly

  95. jonasw

    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

  96. zinid

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

  97. jonasw

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

  98. zinid


  99. zinid

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

  100. jonasw

    no, that’s why we have namespaces

  101. jonasw

    a namespace is defined in a single document

  102. jonasw


  103. Guus

    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.

  104. zinid

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

  105. jonasw

    zinid, define "anyone"

  106. Zash

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

  107. jonasw

    the author and maintainer of the namespace can.

  108. zinid

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

  109. jonasw


  110. jonasw

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

  111. zinid

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

  112. jonasw

    and nobody would approve of that

  113. jonasw


  114. jonasw

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

  115. zinid

    but you can?

  116. zinid

    you = XSF

  117. daniel

    owning the samespace you must

  118. daniel

    owning the namespace you must

  119. jonasw

    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

  120. intosi

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

  121. zinid

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

  122. jonasw

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

  123. Zash

    It's all in our heads anyways

  124. zinid

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

  125. zinid

    as I disagree

  126. daniel

    Zash, namespaces exists only because people believe in them?

  127. jonasw

    zinid, what would you prefer?

  128. zinid

    bumping namespace obviously

  129. daniel

    and if people stop believe the whole system will collapse?

  130. Zash

    daniel: pretty much

  131. jonasw

    zinid, that’s insanity.

  132. jonasw

    bumping the namespace is a major breakage

  133. jonasw

    also, this is an experimental XEP

  134. zinid

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

  135. jonasw

    don’t expect any type of stability in there

  136. zinid

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

  137. jonasw

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

  138. zinid

    but what do you expect from experimental xep?

  139. Flow

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

  140. zinid

    what I expect: the protocol should be formally verified

  141. zinid

    we can debate to death, really

  142. Guus

    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.

  143. Flow

    Then we should write down that rule in xep1

  144. zinid

    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

  145. zinid

    now, implement!

  146. Guus

    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.

  147. Guus

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

  148. daniel

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

  149. zinid

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

  150. daniel

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

  151. zinid

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

  152. daniel

    i see

  153. daniel

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

  154. zinid

    I can use validator to prevent such behaviour among customers

  155. zinid

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

  156. Kev

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

  157. dwd

    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.

  158. dwd

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

  159. daniel

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

  160. jonasw

    daniel, NO

  161. jonasw

    that violates RFC 6120

  162. MattJ

    iq can only have one child

  163. jonasw

    please don’t do that

  164. jonasw

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

  165. MattJ

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

  166. daniel

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

  167. daniel

    This could be seconds or hours

  168. jonasw

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

  169. daniel

    Depending on implementation

  170. jonasw

    quota cleanup cronjob something?

  171. dwd

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

  172. Zash

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

  173. MattJ

    dwd, ?

  174. daniel

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

  175. dwd

    MattJ, Error + original request.

  176. jonasw

    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

  177. Zash

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

  178. daniel

    Jabber.at is doing this

  179. Zash

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

  180. jonasw

    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)

  181. daniel

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

  182. jonasw

    daniel, good point

  183. MattJ

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

  184. pep.

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

  185. jonasw

    pep., you need to foresee every possible condition

  186. pep.

    Can you not extent it later?

  187. daniel

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

  188. jonasw

    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

  189. pep.

    jonasw, yeah I need to read stuff

  190. daniel

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

  191. jonasw

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

  192. jonasw

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

  193. jonasw

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

  194. Zash

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

  195. daniel

    i disagree with that being a substantial change

  196. jonasw

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

  197. jonasw

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

  198. pep.

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

  199. pep.

    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)

  200. mathieui

    you’re automatically subscribed if you become a member afaik

  201. pep.

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

  202. jonasw

    pep., haven’t you been subscribed already?

  203. jonasw

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

  204. jonasw

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

  205. pep.

    I have no email coming from members@

  206. pep.

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

  207. mathieui

    pep., it’s not done yet

  208. pep.


  209. mathieui

    it’s finalized on the 7th I think

  210. jonasw

    2017-12-06 is the meeting

  211. edhelas

    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 ?

  212. daniel

    What particular feature do you need edhelas?

  213. edhelas

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

  214. edhelas

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

  215. SamWhited

    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?

  216. lovetox


  217. lovetox

    it was just there before

  218. daniel

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

  219. Zash

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

  220. lovetox

    edhelas, i would also implement this in gajim

  221. edhelas

    that would be awesome

  222. pep.

    Zash: first come first served

  223. lovetox

    but only for httpupload in short term

  224. edhelas

    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

  225. SamWhited

    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…

  226. edhelas

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

  227. daniel

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

  228. daniel

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

  229. edhelas

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

  230. lovetox


  231. pep.

    Jingle-FT in movim when? :-°

  232. lovetox

    i think the xep means OR

  233. lovetox

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

  234. edhelas

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

  235. daniel

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

  236. daniel

    for what ever reason

  237. edhelas

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

  238. edhelas

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

  239. daniel

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

  240. lovetox

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

  241. lovetox

    so you have to implement the negotiation part

  242. SamWhited

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

  243. lovetox

    but do not have to offer the actual jingle transport

  244. lovetox

    instead you put in httpupload

  245. edhelas

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

  246. daniel

    you also need bob for thumbnails which i find very weird

  247. daniel

    i'm not gonna implement bob

  248. edhelas

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

  249. daniel

    has *anyone* ever implemented bob?

  250. edhelas

    I do

  251. daniel


  252. lovetox

    no edhelas this xep builds up on jingle FT

  253. edhelas

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

  254. lovetox

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

  255. daniel

    well yes. but the counterpart has to be online

  256. daniel

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

  257. pep.

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

  258. edhelas

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

  259. daniel

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

  260. daniel

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

  261. edhelas

    yeah I understand

  262. edhelas

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

  263. daniel

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

  264. daniel

    maybe file name

  265. daniel

    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.

  266. edhelas

    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

  267. daniel

    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

  268. daniel


  269. lovetox

    sims is just not trying to be a better OOB

  270. daniel


  271. lovetox

    thats why it reuses jingle stuff

  272. daniel

    It's doing something completely different

  273. edhelas

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

  274. lovetox

    i dont think so edhelas

  275. lovetox

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

  276. lovetox

    and if its good

  277. SamWhited

    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

  278. lovetox

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

  279. lovetox

    really SamWhited ?

  280. lovetox

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

  281. SamWhited

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

  282. lovetox

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

  283. lovetox

    he can choose if he wants to request it via jingle

  284. lovetox

    or httpupload

  285. SamWhited

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

  286. lovetox

    or any other FT method invented in the future

  287. SamWhited

    And basically what OOB does except in a more general way

  288. SamWhited

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

  289. lovetox

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

  290. SamWhited

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

  291. lovetox

    i think we going in circles

  292. lovetox

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

  293. lovetox

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

  294. daniel

    neither has sims though?

  295. SamWhited

    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.

  296. lovetox

    daniel i think you can just add more file tags

  297. lovetox

    with different images

  298. SamWhited

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

  299. daniel

    within the same reference?

  300. daniel

    how do i match a source and a file then?

  301. lovetox

    nah i think im confusing this

  302. lovetox

    this was 0084 with different avatar sizes or

  303. SamWhited

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

  304. lovetox

    yeah ok, but whats bad about this?!

  305. Zash

    It's a pointer.

  306. lovetox

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

  307. lovetox

    not just a bit more, WAY more

  308. SamWhited

    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

  309. lovetox

    so thats what i asked you 4 minutes ago

  310. lovetox

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

  311. Zash

    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.

  312. lovetox

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

  313. lovetox

    let it be what it is

  314. daniel

    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'

  315. daniel

    or SIMS can move into that direction

  316. jonasw

    I’d prefer the latter

  317. jonasw

    SIMS seems like nice framework to extend

  318. SamWhited

    I agree

  319. jonasw

    the MUST support Jingle-FT is weird though

  320. jonasw

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

  321. Zash

    jonasw: Why is that weird?

  322. daniel

    and the bob thumbnails are even more weird

  323. jonasw

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

  324. Zash

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

  325. jonasw

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

  326. SamWhited

    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.

  327. jonasw

    or BOB

  328. daniel

    expect that it says must support jingle ft

  329. daniel

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

  330. SamWhited

    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

  331. jonasw

    maybe post that to the list, daniel?

  332. SamWhited

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

  333. lovetox

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

  334. lovetox

    instead of reinventing the same tags under a new namespace

  335. daniel

    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

  336. lovetox

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

  337. jonasw

    daniel, but spark the discussion maybe?

  338. daniel

    jonasw, that's gonna get ignored anyway

  339. jonasw

    gotta love your optimism

  340. daniel

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

  341. daniel

    and those are things i actually care about

  342. SamWhited

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

  343. Kev

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

  344. daniel


  345. lovetox

    i will post the questions to the list :)

  346. lovetox

    i care about sims :)

  347. lovetox

    do we really need thumbnails?

  348. edhelas

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

  349. lovetox

    with the metadata i can display some placeholder

  350. edhelas

    like many other messaging solutions are doing now

  351. edhelas

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

  352. daniel

    edhelas, isn't that what references is doing?

  353. lovetox

    edhelas thats what the end and begin is for

  354. lovetox

    so you can embed it in a message

  355. edhelas

    let me rephrase that :)

  356. edhelas

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

  357. edhelas

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

  358. lovetox

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

  359. lovetox

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

  360. lovetox

    with beginn and end

  361. edhelas

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

  362. daniel


  363. daniel

    you probably need a og extension to references

  364. daniel

    like sims but with og data

  365. edhelas

    og ?

  366. daniel


  367. daniel

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

  368. daniel

    because you can put all that into og

  369. edhelas

    kind of yes

  370. edhelas

    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

  371. pep.

    rrr heroku apps and their lack of tls :(

  372. pep.

    Or people failing to set it up correctly

  373. edhelas

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

  374. daniel

    what do you mean?

  375. edhelas


  376. daniel

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

  377. daniel

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

  378. daniel

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

  379. edhelas

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

  380. daniel

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

  381. daniel

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

  382. daniel

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

  383. daniel

    (opt in)

  384. edhelas

    yes I understand

  385. daniel

    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

  386. edhelas

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