XSF Discussion - 2018-04-03

  1. edhelas

    hello everyone

  2. Seve/SouL


  3. edhelas


  4. Maranda

    ^ *yawn* tbh

  5. Ge0rG


  6. Maranda

    Ge0rG stop leaking all my precious metas ™️😪

  7. edhelas

    got a question for you

  8. Ge0rG


  9. edhelas

    what do you think about using MAM to "discover" Pubsub nodes

  10. Maranda


  11. Andrew Nenakhov

    edhelas, > https://blog.torproject.org/sunsetting-tor-messenger Good riddance

  12. edhelas

    <iq to='pubsub.shakespeare.lit' type='set' id='juliet1'> <query xmlns='urn:xmpp:mam:2' queryid='f28' /> </iq>

  13. edhelas

    without the "node" attribute, then I can paginate on those nodes

  14. Maranda already spoke about the topic, "just.. No"

  15. Maranda

    That's more about adding some result filtering option to disco#items queries (and something simpler than having to implement connection nodes) imho

  16. Maranda


  17. MattJ

    edhelas, indeed, aren't you just looking for RSM on disco#items? Which is one of the things RSM was created for

  18. Kev

    But no-one* implements, unfortunately.

  19. edhelas

    I'd like to also order

  20. Kev

    [* I've not seen it in the wild, in any case]

  21. MattJ waits for the *

  22. MattJ


  23. edhelas

    RSM would be nice for pagination indeed

  24. MattJ

    I was hoping for *except we almost have an implementation in Swift

  25. Kev

    We've got RSM in Swift, but not plumbed into disco.

  26. edhelas

    *soon to be released

  27. edhelas

    also filtering

  28. edhelas

    but it would be the same kind of things for conferences

  29. edhelas

    "give me the top conferences of this service", "conferences with the most users"

  30. edhelas

    and I want only the top 50 ones

  31. Maranda

    And while RSM does it for paging I'm not sure it does it to filter results by <insert something, e.g. name> as long as I didn't miss any bit in {xep 30} which does

  32. Bunneh

    Maranda: Service Discovery (Standards Track, Final, 2017-10-03) See: https://xmpp.org/extensions/xep-0030.html

  33. Maranda

    I suppose "hierarchies"?

  34. Kev

    You could use disco nodes for the filtering, and RSM on that :)

  35. edhelas

    Kev what do you mean ?

  36. Kev

    If you wanted to build filtering into disco results, you could define a way of encoding the filters in the disco node, and then use RSM in the 'usual' way for the disco results.

  37. edhelas

    I don't see how you can do that

  38. Maranda

    Kev, I think the problem here was having the server filter result items by say a portion of the name e.g. "urn:xmpp:microblog" and return only the matching items

  39. Maranda

    Not the client retrieving everything and then filter

  40. Kev


  41. Kev

    I repeat, you could just define a syntax for using nodes as a filter.

  42. Kev


  43. Kev


  44. edhelas

    I know that there's the pubsub#type attribute in Pubsub

  45. Maranda

    I guess you could arbitrarily use type or something else, but whatever needs implementation both sides

  46. Maranda

    Aka hax

  47. Maranda

    Something more definite in the spec itself would be better imho (but then that would fall into the same issues)

  48. edhelas


  49. edhelas

    I'm kinda lost

  50. Maranda

    And we're talking about filtering the containers aka the nodes 'emselves so can't use nodes, pubsub doesn't allow for hierarchy/leaf types afair

  51. Maranda


  52. Maranda

    As long as not using collections which is overly convoluted

  53. edhelas

    do we have one Pubsub Collection implementation in the wild that is actuavelly used ?

  54. Holger

    ejabberd has code for it.

  55. edhelas

    I'm still finishing the 0060 pubsub implementation in ejabberd

  56. Holger

    No idea whether it's actually used by anyone :-)

  57. edhelas

    Holger as far as I saw, it's far from be done

  58. Holger

    Ah. No idea.

  59. Maranda

    Problem here we have 3 xeps to deal with disco, pubsub and microblogging

  60. ralphm

    I know it is used, but personally I think the current spec is not great. Except, maybe, the root node.

  61. Maranda


  62. edhelas

    Maranda it's more than Pubsub

  63. edhelas

    again, how can I discover conferences on my own server without listing 10K conferences from the service ?

  64. ralphm

    I think that in most cases where you might think that collection nodes are a good idea, you're probably better of with node-as-code.

  65. Maranda

    I said "disco, pubsub and microblogging"...

  66. edhelas

    ah yeah sorry

  67. edhelas

    ralphm maybe we can deprecate Collection ?

  68. ralphm

    I guess we could, but who would benefit from this exactly?

  69. edhelas

    who is benefiting from it actually ?

  70. ralphm

    The specification is already deferred

  71. Kev

    Collections is a bit of a mess when you end up trying to use it, so I'm not sure it's an altogether stupid suggestion.

  72. edhelas

    I had a look at collection many times, also for social network usage, I never ended up to find a nice way to use AND implement i

  73. edhelas


  74. ralphm

    I.e. you can't go to deferred without going to Draft, first.

  75. edhelas

    I think that we better design Pubsub as a flat tree behind the services, but with a good filtering/ordering/pagination system to explore the nodes

  76. edhelas

    then a client that want to explore the network will be able to grab lots of interesting data quickly

  77. edhelas

    and not doing recursive exploration, loading entire dump of nodes and exploring each of thems

  78. ralphm

    edhelas: without XEP-0248, which is Deferred, there is only a bag of nodes, without any organization. If that aligns with your idea of a flat tree, yay.

  79. edhelas


  80. ralphm

    I like doing nothing and achieve results :-D

  81. edhelas

    MAM got a lot of nice features, including filtering on results, pagination

  82. edhelas

    too bad it's called "message archive"

  83. edhelas

    because it could be used for many other use cases

  84. edhelas

    like discovery

  85. Holger

    Well the pagination is 0059, it's just the filtering syntax you're missing, no?

  86. edhelas

    as well

  87. Holger

    Or sorting, which MAM also doesn't have.

  88. edhelas

    yup :D

  89. Holger

    I.e. "sort by number of participants/subscribers" or so.

  90. edhelas

    both 3

  91. Holger

    So I don't quite buy "MAM is perfect just has the wrong name" :-P

  92. Holger

    I totally see your use case and would think this just[tm] needs a bit new syntax.

  93. edhelas

    or we can revive SQL over XMPP

  94. edhelas ---> []

  95. Ge0rG

    edhelas: I propose we use an HTTP-REST abstraction in between. OData is my favorite for that.

  96. Link Mauve

    “11:57:15 ralphm> I.e. you can't go to deferred without going to Draft, first.”, IIRC we did that at least once, and I’d like to propose a change to the process to allow it more.

  97. edhelas

    more seriously if we can achieve, in a XEP, a way to deal with those 3 things, pagination (RSM), filtering (MAM) and sorting, we can be good

  98. Link Mauve

    We’ve been telling people to implement deferred XEPs for a while, because a lot of them are useful, yet there are a ton of useless deferred ones.

  99. edhelas

    also MAM can then reuse that, I mean, in ejabberd MAM is basically querying the archives table :p

  100. Holger

    edhelas: I see the idea, I'm just not sure a generic filtering/sorting syntax really simplifies things compared to adding whatever you need to 0045/0060.

  101. edhelas

    this XEP can be reused in lots of places "give me all the Holger messages, sorted by date in this chatroom, by pages of 20"

  102. edhelas

    Holger yeah maybe

  103. edhelas

    I'm not coming wih a proper solution here, just that I can't scale Pubsub for now

  104. edhelas

    especially because of this disco issue

  105. Holger

    Maybe. I'm just saying that it's not obvious to me that this works as nicely for filtering/sorting as it does for pagination. You want different filtering/sorting fields for the different use cases.

  106. edhelas

    but that's the same thing with disco overall :D XMPP is just not that good with discovery, too "raw"

  107. edhelas


  108. edhelas

    Holger what about filtering/ordering by https://xmpp.org/extensions/xep-0060.html#entity-metadata

  109. edhelas

    I have to do a PR in that thing as well, to expose more metadata

  110. edhelas

    including pubsub#access_model and pubsub#last_update

  111. ralphm

    Link Mauve: I strongly believe that if you need to encourage people to implement Deferred specifications, you should make an effort to bring it to Draft.

  112. ralphm

    Going from Deferred to Deprecated doesn't make sense to me.

  113. Link Mauve

    I agree, but that rarely happens.

  114. Link Mauve

    Or at least not in a timely manner.

  115. ralphm

    Deferred simply means: nobody's touched this in 12 months (used to be 6 I think) and nobody cares to move it forward in the process.

  116. edhelas

    also you cannot ask developpers to implement a new XEP, they are implementing it if they find it valuable

  117. ralphm

    XEP-0248 hasn't been touched since 2010, so I'd say it is rather dead. There doesn't seem any value in making it Deprecated.

  118. ralphm

    edhelas: a new XEP is not Deferred

  119. edhelas

    sorry, defered

  120. ralphm

    Sure, people that have a particular use case might not care about the actual status.

  121. ralphm

    We currently only have 11 Deprecated XEPs and most of them were superseded by either RFCs or new protocol. The only exception, arguably, is XHTML-IM.

  122. Link Mauve

    edhelas, we make sure these developers will continue to implement deprecated things, by making experimental ones scary and never advancing them, and by deferring them.

  123. ralphm

    To be honest, the XHTML-IM spec should have a description of why it was deprecated.

  124. edhelas

    what is the state of bookmark2 by the way ?

  125. ralphm

    (and probably also mark XEP-0393 as a successor if that was the intent of the Council)

  126. ralphm

    I see that XEP-0393 does mark itself as a successor to XEP-0071, so maybe it is just an editorial issue. Dave Cridland, SamWhited what is the idea here?

  127. Anu

    Funny thing, what I find more difficult is keeping track of when the spec changes

  128. Anu

    Short of being in these groups I don’t know how I would know that something I implemented years ago has been updated or changed

  129. Anu

    Well that and someone telling me something is broken

  130. MattJ

    Are you on the standards mailing list?

  131. Anu


  132. MattJ

    That's the central place for notifications about updates

  133. Anu

    I have been in the past but since I do stuff as a hobby more than professionally

  134. Anu

    I’m often out of the loop or behind

  135. Anu

    Any other protocol has an overall version of the api

  136. Zash

    What protocols?

  137. MattJ

    Anu, there was a proposal for that recently on the standards list ;)

  138. Anu

    There are many closed protocols that use xmpp as a backend but expose it as a rest Api

  139. Anu

    They make xmpp easier to use and develop for. We debate the restful part but the fact that there is an api version means there less of a moving target

  140. Anu

    The largest closed garden messaging services are or started as xmpp servers with push support and rest interfaces

  141. Anu

    Api versioning could be as simple as having a release schedule. Xep are always in development but X times a year we publish the new spec .

  142. Anu

    There are a lot of xeps and they all look equally important

  143. Anu

    But in reality some are heavily supported and others aren’t

  144. Ge0rG

    Anu: XEP-0387 is supposed to provide an up-to-date overview of the most important ones for IM

  145. Ge0rG

    Anu: as somebody who's not following closely, it would be nice if you could point out where you struggle. I'd love to provide resources for newcomers in the wiki or maybe even on the main page in the future

  146. Maranda

    Regarding disco#items filtering, sorry but had no cell where I was, problem is we're dealing with 3 different xeps each one wanting a different thing.. As usual.

  147. edhelas

    Maranda I'm currently talking with order

  148. edhelas

    we maybe have an idea :) define two new XEPs Result Order Management and Result Filtering Management

  149. edhelas

    the service expose trough the disco#info the field that you can order and filter on

  150. edhelas

    and boom, you apply just RSM like things

  151. edhelas


  152. Maranda


  153. Holger

    Yes, with me.

  154. Holger


  155. Holger

    Seems my client failed to change my nick to 'Order' before making that statement.

  156. Maranda

    Result order management is needed for what beside the obvious?

  157. Holger

    Received error packet [conflict] from <xsf@muc.xmpp.org/Order>

  158. Maranda

    Changing order based on x?

  159. MattJ

    Multiple devices under the same nick

  160. edhelas

    Maranda that's it

  161. Holger

    MattJ: Ah, right.

  162. Maranda

    I have a Jappix dejavu for some reason.

  163. Ge0rG

    MSN nicknames are a problem still.

  164. Holger

    TBH I'm still not convinced we need a new XEP. As opposed to just adding a data form to the disco request like MAM does today.

  165. Maranda

    Yes, agreed.

  166. Holger

    Ge0rG: We have no problems, we have opportunities.

  167. Maranda

    I came out with something even simpler than using DFs, but that's the idea.

  168. Holger

    (Sorry already had a bullshit bingo meeting today.)

  169. Ge0rG

    Holger: let's make an MVP!

  170. MattJ

    Prosody trunk == your MVP

  171. Ge0rG

    From MVP to ICO in only 0.5 Bitcoins!

  172. Ge0rG

    A coworker of mine is quitting to do something with the blockchain. Let's see if I can talk him out of it again.

  173. Maranda

    Ge0rG I suggest just blocking him with a chain.

  174. Ge0rG

    is that like clubbing him with books?

  175. Maranda

    On the nearest lamp post

  176. Maranda

    Irregardless of the nature of the article http://www.dailymail.co.uk/news/article-1281541/Chinese-boy-chained-lamp-post-father-tried-sell-street.html this gives an idea Ge0rG

  177. Maranda


  178. Ge0rG

    Hm. https://wiki.xmpp.org/web/Special:Random is rather worthless because you always end up on random membership application pages.

  179. Ge0rG

    Maranda: was that boy to be sold or to be rented out?

  180. Maranda

    "Irregardless of the nature of the article" you know what to do with the "chain" and your colleague

  181. Maranda probably failed at some humor attempt

  182. Maranda

    Or google failed bringing up a good piccie

  183. Ge0rG

    Hm. https://wiki.xmpp.org/web/Facebook links to a non-existent page.

  184. Maranda

    Ge0rG, more adapt http://www.mannequin-man.com/machinemart6.jpg

  185. Maranda

    For some reason the first results of "chained to a lamp post" all brought either bikes or stuff that is all but humouristical

  186. Ge0rG

    So... I still wonder if we can solve multi-client/mobile MUC by implementing: - account joins all bookmarks on behalf of user - account determines notification-worthiness - account sends to-be-defined (push) notification to client - client transparently joins and gets backlog from MAM

  187. Maranda

    "Account joins all bookmarks on behalf of client"?

  188. Maranda

    Is that still the bnc idea?

  189. Ge0rG

    Maranda: yes

  190. Ge0rG

    It's a good, strong idea.

  191. Holger

    It's an opportunity.

  192. Maranda

    Questions... when "is it supposed to join" and "how long is it supposed to stay joined"

  193. moparisthebest

    how is the POC prosody module to do that working out?

  194. Ge0rG

    Maranda: when bookmarks

  195. Maranda

    "When bookmarked" and "for eternity from that" has its issues ™️

  196. Ge0rG

    Maranda: I know. Tell the MIX.

  197. Ge0rG

    Maranda: I would probably go with something like "at most N (=14) days after the last client disconnected"

  198. Ge0rG

    But obviously, having a zombie in a MUC is not desirable

  199. moparisthebest

    that'd just be an account/server setting

  200. Ge0rG

    Maybe also "when the last client session is killed"

  201. Maranda

    14 days on very busy room is a lot but still better than forever

  202. Zash

    Anyone tested my minimix?

  203. Ge0rG

    moparisthebest: users won't be able to figure it out. Probably not even server admins

  204. Ge0rG

    Zash: tell us how

  205. Zash

    Ge0rG: I'm sure I put it in prosody-modules

  206. Ge0rG

    Zash: I'm not sure you told us that before

  207. Ge0rG

    so https://modules.prosody.im/mod_minimix.html

  208. Tobias

    https://blog.torproject.org/sunsetting-tor-messenger what do they mean with centralized metadata problem? isn't it decentralized?

  209. moparisthebest

    oh that's different than the one I (and I think you) were thinking of where each contact has their own .onion address, that looks like 'pidgin over tor'

  210. Maranda

    I think they just brought a random word to add between the last one and "problem"

  211. Maranda

    But that's me

  212. moparisthebest

    The aim was to provide a chat client that supported a wide variety of transport networks like Jabber (XMPP), IRC, Google Talk, Facebook, Twitter; had an easy-to-use graphical interface; and configured most of the security and privacy settings automatically with minimal user intervention.

  213. moparisthebest

    so they are just saying all of those are centralized (xmpp least of which, but still has a good amount of metadata)

  214. vanitasvitae

    > https://blog.torproject.org/sunsetting-tor-messenger what do they mean with centralized metadata problem? isn't it decentralized? Iwas thinking the same.

  215. Ge0rG

    vanitasvitae: it's more centralized than in p2p messengers

  216. moparisthebest

    in other words it is not https://en.wikipedia.org/wiki/TorChat

  217. Maranda

    moparisthebest, do you realize the intrinsical dumbness of that article though, "you don't want to scatter anything around" but you use an intermediary entity, oh rly?

  218. Maranda

    Aka If you're so concerned, just go serverless and GTFO with it.

  219. moparisthebest

    I still think much can be done with XMPP towards the 'no metadata' goal, or at least 'minimal metadata'

  220. Kev

    Some things can, but it's hard to get away from an envelope, I think

  221. Ge0rG

    If you want E2EE and minimal meta-data, XMPP is just not the right protocol.

  222. moparisthebest

    the initial plan I have in my mind, in a 2 server scenario, prevents any 1 server from knowing the endpoints

  223. Ge0rG

    moparisthebest: you want to reinvent tor at the message routing layer.

  224. moparisthebest

    it's not actually that complicated, but perhaps that's a good summary

  225. moparisthebest

    basically bob@bob.com communicates with tom@tom.com, but server bob.com only knows bob@bob.com is communicating with tom.com, and tom.com only knows tom@tom.com is communicating with bob.com

  226. Ge0rG

    moparisthebest: and then you also need to tie the identity of users into cryptographic identifiers, and at that moment you could just use Tor for the plumbing

  227. moparisthebest

    yep, but we already have that with omemo and pgp so

  228. moparisthebest

    going with tor is already done with torchat, it doesn't give me all the nice things xmpp does though

  229. Ge0rG

    moparisthebest: both OMEMO and PGP suck regarding identity management. There is no strong binding between your JID and your key.

  230. Ge0rG

    moparisthebest: you could do serverless XMPP between onion hosts.

  231. moparisthebest

    sounds like it'd eat battery though

  232. Ge0rG

    moparisthebest: I'm not so sure. You need to get some tor routing DHT data, that's some hundred megs a week or so

  233. moparisthebest

    one of the downsides of my plan is it makes any type of content or metadata based spam blocking worthless, but that sounds like someone else's problem ¯\_(ツ)_/¯ :)

  234. MattJ

    Ge0rG, having no strong binding between your JID and your key is a bonus in the context of the metadata thing

  235. MattJ

    I could message you from a new random JID every day, but you would still know it was me

  236. Ge0rG

    MattJ: except I would need to analyze your key to decrypt, and attackers could do so as well to identify you

  237. moparisthebest

    only the thing meant to decrypt it should be able to do that

  238. Kev

    Ge0rG: unless it's sign then encrypt.

  239. Ge0rG

    And how am I supposed to respond in this scheme?

  240. Kev

    You don't bother, it was probably spam anyway :D

  241. Maranda


  242. MattJ

    Ge0rG, who is the attacker in that case?

  243. moparisthebest

    in my mind, the server keys are in DNS, so you look up the key for otherserver.net, encrypt the fact that you are responding to bob@otherserver.net, and send it to otherserver.net

  244. MattJ

    The premise is that I can use a different server for each message if I wanted

  245. Maranda

    Can you?

  246. Maranda


  247. Maranda isn't anymore certain how much of this discussion is serious and how much is sci-fi.

  248. moparisthebest

    I guess you could, the premise is a 'person' would be the owner of a certain key, and you'd just respond to whatever JID they told you to at the time

  249. Dave Cridland

    moparisthebest, So the problem with hiding metadata to the server level is that once you add in things like blocklists, it starts to behave pretty badly.

  250. Dave Cridland

    moparisthebest, On the other hand, you can use anonymous MUCs to get what you want quite usefully, if you choose. Still needs sign->encrypt, but MLS actively hides the participants, for example.

  251. moparisthebest

    not from the server though Dave Cridland ?

  252. moparisthebest

    but yes, you'd have to be careful not to use bookmarks/blocklists/etc when hiding metadata from your server

  253. Dave Cridland

    moparisthebest, MLS hides the metadata entirely, but XMPP needs it visible for routing. So if you use an anonymous MUC, your server knows only that you're talking to a person in the MUC, as does theirs. The MUC server knows both ends, though.

  254. Zash

    That's not going to scale tho

  255. MattJ

    Every DXMPP server allows anonymous login and anonymous MUCs. Users each choose a login server at random, and then agree on a MUC JID on a random MUC server...

  256. Ge0rG

    MattJ: and then they talk about random stuff in that MUC.

  257. MattJ

    What else do you talk about after going to all that effort?

  258. Ge0rG

    that reminds me of amateur radio. You build complicated devices to talk to other nerds about the complicated devices you built.

  259. Maranda


  260. Ge0rG

    devices, tacos and knee implants.

  261. Maranda

    I'd need a shoulder implant more atm probably :P

  262. Zash

    Sounds like how GNU Social was a social network for talking about GNU Social

  263. Ge0rG

    I need a gatling gun implant.

  264. Zash

    Or how 3D printers are devices for producing parts for 3D printers

  265. moparisthebest

    Dave Cridland, xmpp needs only certain parts for routing, not all the parts it has now

  266. moparisthebest

    it just needs the last and next hop, not both endpoints

  267. Dave Cridland

    moparisthebest, Sure. That's basically Tor, right?

  268. moparisthebest

    it's xmpp just with an extra bit

  269. moparisthebest

    but, kinda

  270. Maranda

    I'm dead curious to see the practical result.

  271. jjrh

    is there a xep or is anyone working on one for emoji reactions?

  272. Zash

    I think there's more than one

  273. Zash

    -xep attaching

  274. Bunneh

    Zash: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html

  275. Zash

    -xep references

  276. Bunneh

    Zash: References (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0372.html

  277. Zash

    Those, I think?

  278. SamWhited

    Those may give you the building blocks to build such a system, but I don't think there's anything standardizing that feature in particular.

  279. SamWhited

    (and I'm not aware of anyone working on it)

  280. jjrh

    buddy sent me https://api.slack.com/docs/message-buttons

  281. jjrh

    which is a interesting feature

  282. Kev

    SamWhited: We're not quite there yet, but we're starting to build up References stuff.

  283. Kev

    The issue with emoji reactions is that while sending them is straightforward, dealing with them very much isn't.

  284. Kev

    We need a situation where you request a message from MAM, and you get all the references to it as well, correlated into a useful format so you don't get 30 'likes' in your archive a day later that you somehow have to correlate client-side.

  285. Zash

    So References is going to do everything?

  286. Kev

    Depends what 'everything' is.

  287. Kev

    I don't see a reason not to use References as the framework for everything that's a reference.

  288. Kev

    But I'm not intending squeezing URL references, emoji reactions, quotes, etc. all into the one XEP.

  289. Zash

    I mean, it looks like References and Attaching have some overlap

  290. Kev

    They do, yeah.

  291. jjrh

    I have heard from multiple people that emoji reactions are the killer feature of slack

  292. moparisthebest

    I still don't get what they give you over a well timed

  293. jjrh

    people use them for stuff like "do we have quorum for the XSF boardmeeting?" and you do +1 or whatever

  294. moparisthebest


  295. moparisthebest

    or whatever

  296. Zash

    I've learned to take what people say the killer feature is with some salt.

  297. moparisthebest

    but I guess I'm oldschool or something

  298. jjrh

    well it's more "is emoji reactions the killer feature" and instead of agreeing or disagreeing you do thumbs up or thumbs down. and in theory we can go back in time and go "yeah everyone thought it was a shit idea" without reading the following messages

  299. Chobbes

    I mean, emoji reactions don't seem like much, but people like them and get used to using them. They're great for quick agreements on things. Sending smilies and frownies creates a lot more noise.

  300. Kev

    Zash: On the one hand, yes.

  301. moparisthebest

    seems like it'd be useful on something like twitter, not so much instant messaging

  302. Kev

    On the other, people really do get these little features into their workflow and they add value.

  303. jjrh

    not saying it's THE killer feature - but it's a feature I hear - to my surprise - a lot of people use.

  304. Kev

    I don't use them as much as some folks, but it's useful.

  305. Zash

    Also, people tend to differ on which feature is the killer feature. Everyone has their own favorite.

  306. Kev

    And one message with "30👍" beats a message with 30 replies each just saying 'great' or something by a long margin.

  307. Chobbes

    moparisthebest, a lot of people use that feature with instant messaging. It's shockingly useful. I wouldn't say it's the killer feature, but it's definitely a good feature that's well liked and well used.

  308. Zash

    Last week it was stickers. XMPP can't succeed without stickers! It's the killer feature!

  309. Zash

    Before that it was something else.

  310. jjrh

    what are stickers?

  311. daniel

    I'd certainly implement it if someone writes a xep

  312. Zash


  313. Zash

    daniel: Or you could implement it and XEP-ify what you did.

  314. Kev

    daniel: It's one of the oh-so-many things on my list.

  315. Zash

    The age old question, which comes first, implementation or specification :)

  316. Kev

    MAM is the real killer for it, otherwise it's trivial.

  317. Zash

    Kev: The problem you talk of, it's basically the same as with corrections, right?

  318. Kev

    And receipts.

  319. Kev


  320. Kev

    Both of which I'm considering reframing in terms of References in the hope that MAM can just be references-aware, and not million-different-things-without-future-proofing aware.

  321. Zash

    Aka "graph-like queries on log-style data is messy"

  322. Kev

    Because message logs are actually message forests where each IM message is the root of a tree with leaves of emoji, corrections, receipts, URLs, ...

  323. Kev

    Thankfully not at all messy.

  324. MattJ

    Encode messages into a DAG structure, switch to JSON and transport them over HTTP

  325. Ge0rG

    https://github.com/jabbercat/jabbercat/issues/80 proto XEP for reactions be here

  326. Ge0rG

    jjrh: ^

  327. pep.

    > Fitzpatrick modifiers; Aggregate or show separately? If aggregate, show unmodified version or most-voted-for version? (I tend to unmodified since the "unrealistic skin tone" is probably least controversial) On Mattermost (and probably slack?) you can click on the reactions that people already sent, to send one of the same type, aggregation here would prevent this

  328. Ge0rG

    pep.: what if you make a happy white and a sad black Emoji (slack supports that)? Is that Racial Segregation?

  329. Zash

    We need blue skin tone modifiers

  330. pep.

    Ge0rG, do I care?

  331. pep.


  332. Zash

    Scale the font snize?

  333. Zash

    Scale the font size?

  334. pep.

    Ge0rG, that was sarcastic right?

  335. Ge0rG

    pep.: you will care, as soon as the Twitter SJW mob finds out

  336. Ge0rG

    pep.: I wish it was

  337. pep.

    Well it's already possible on any of the other platforms I'm sure

  338. Maranda

    hmmm how many spim hits consist enough of an offense to justify a s2s ban? 🤔

  339. Maranda needs a reasonable default.

  340. pep.

    Ge0rG, hmm I take that back, I'm not able to find fitzpatrick modified emojis in Mattermost's selection.

  341. Maranda

    ... and I know whatever I pick is probably too low :P

  342. pep.

    You can input one yourself of course, but not as a reaction I think. Or you'd have to add it manually as a custom emoji maybe

  343. Maranda


  344. Maranda


  345. Ge0rG

    Maranda: you don't need to ban domains if you can ban users fast enough

  346. pep.

    Maranda, I would say increase the number of parameters you take into account, not just the number of hits. On what period of time, how often etc.

  347. Maranda

    I'm not sure I really need to ban anything, but I'm implementing a logic for modules to temporarily ban remote servers based on hits.

  348. Maranda

    (default is 2 days)

  349. Zash

    Any local users having any users on the offending server in their roster?

  350. Zash

    If not, ban instantly and forever!!!11!!eleven

  351. Maranda


  352. Maranda

    85 sounds like a nice number anyways

  353. Maranda

    (my year of birth also)

  354. Maranda

    and random()'ed too!

  355. pep.

    Ge0rG, in any case if we aggregate we'll get reports like: "My reaction doesn't show up"

  356. pep.

    also that's a client impl. detail, right?

  357. pep.

    Not a protocol issue

  358. Ge0rG

    pep.: how do you want to achieve consistency without writing such details into the XEP?

  359. pep.

    You can suggest that sure

  360. Ge0rG

    On the other hand, not being precise gives us the opportunity to differentiate on quality of implementation.

  361. Ge0rG

    Another instant messaging flame war... https://news.ycombinator.com/item?id=16743055

  362. Zash

    Great, we need more of those!

  363. Zash


  364. Zash


  365. Zash


  366. Ge0rG

    Zash: we need a good setup guide for a modern prosody

  367. Zash

    Ge0rG: Thanks for volunteering to work on our docs. :)

  368. Ge0rG

    Zash: thanks for placing that scary big red warning banner at the top of https://prosody.im/doc/public_servers

  369. Zash

    Like the ssl config page?