edhelaswithout the "node" attribute, then I can paginate on those nodes
Marandaalready spoke about the topic, "just.. No"
MarandaThat's more about adding some result filtering option to disco#items queries (and something simpler than having to implement connection nodes) imho
Marandas/connection/collection/
MattJedhelas, indeed, aren't you just looking for RSM on disco#items? Which is one of the things RSM was created for
Yagizahas joined
KevBut no-one* implements, unfortunately.
edhelasI'd like to also order
Kev[* I've not seen it in the wild, in any case]
MattJwaits for the *
MattJAww
edhelasRSM would be nice for pagination indeed
MattJI was hoping for *except we almost have an implementation in Swift
KevWe've got RSM in Swift, but not plumbed into disco.
edhelas*soon to be released
edhelasalso filtering
edhelasbut it would be the same kind of things for conferences
edhelas"give me the top conferences of this service", "conferences with the most users"
Tobiashas joined
edhelasand I want only the top 50 ones
ThibGhas joined
alexishas left
Ge0rGhas left
Alexhas joined
winfriedhas left
MarandaAnd 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
BunnehMaranda: Service Discovery (Standards Track, Final, 2017-10-03)
See: https://xmpp.org/extensions/xep-0030.html
MarandaI suppose "hierarchies"?
KevYou could use disco nodes for the filtering, and RSM on that :)
edhelasKev what do you mean ?
Alexhas left
KevIf 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.
tahas left
edhelasI don't see how you can do that
alexishas joined
danielhas left
MarandaKev, 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
MarandaNot the client retrieving everything and then filter
KevIndeed.
Valerianhas left
KevI repeat, you could just define a syntax for using nodes as a filter.
Kev)
Kev:)
Valerianhas joined
edhelasI know that there's the pubsub#type attribute in Pubsub
Valerianhas left
Valerianhas joined
Valerianhas left
j.rhas joined
efrithas joined
MarandaI guess you could arbitrarily use type or something else, but whatever needs implementation both sides
danielhas left
MarandaAka hax
danielhas joined
winfriedhas joined
MarandaSomething more definite in the spec itself would be better imho (but then that would fall into the same issues)
Valerianhas joined
edhelasyeah
edhelasI'm kinda lost
andyhas left
Valerianhas left
MarandaAnd 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
Marandas/hierarchy/branch/
MarandaAs long as not using collections which is overly convoluted
edhelasdo we have one Pubsub Collection implementation in the wild that is actuavelly used ?
Holgerejabberd has code for it.
edhelasI'm still finishing the 0060 pubsub implementation in ejabberd
HolgerNo idea whether it's actually used by anyone :-)
edhelasHolger as far as I saw, it's far from be done
HolgerAh. No idea.
MarandaProblem here we have 3 xeps to deal with disco, pubsub and microblogging
ralphmI know it is used, but personally I think the current spec is not great. Except, maybe, the root node.
Maranda😎
Andrew Nenakhovhas left
edhelasMaranda it's more than Pubsub
edhelasagain, how can I discover conferences on my own server without listing 10K conferences from the service ?
ralphmI 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.
MarandaI said "disco, pubsub and microblogging"...
goffihas left
edhelasah yeah sorry
edhelasralphm maybe we can deprecate Collection ?
ralphmI guess we could, but who would benefit from this exactly?
edhelaswho is benefiting from it actually ?
ralphmThe specification is already deferred
KevCollections 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.
Andrew Nenakhovhas joined
edhelasI 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
edhelas*it
andyhas joined
ralphmI.e. you can't go to deferred without going to Draft, first.
edhelasI 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
edhelasthen a client that want to explore the network will be able to grab lots of interesting data quickly
edhelasand not doing recursive exploration, loading entire dump of nodes and exploring each of thems
ralphmedhelas: 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.
edhelasyes
ralphmI like doing nothing and achieve results :-D
edhelasMAM got a lot of nice features, including filtering on results, pagination
edhelastoo bad it's called "message archive"
edhelasbecause it could be used for many other use cases
edhelaslike discovery
HolgerWell the pagination is 0059, it's just the filtering syntax you're missing, no?
edhelasas well
HolgerOr sorting, which MAM also doesn't have.
edhelasyup :D
HolgerI.e. "sort by number of participants/subscribers" or so.
edhelasboth 3
HolgerSo I don't quite buy "MAM is perfect just has the wrong name" :-P
HolgerI totally see your use case and would think this just[tm] needs a bit new syntax.
tuxhas joined
edhelasor we can revive SQL over XMPP
edhelas---> []
Ge0rGedhelas: I propose we use an HTTP-REST abstraction in between. OData is my favorite for that.
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.
SaltyBoneshas left
edhelasmore 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
Link MauveWe’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.
edhelasalso MAM can then reuse that, I mean, in ejabberd MAM is basically querying the archives table :p
alexishas joined
Holgeredhelas: 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.
tahas joined
edhelasthis XEP can be reused in lots of places "give me all the Holger messages, sorted by date in this chatroom, by pages of 20"
edhelasHolger yeah maybe
winfriedhas left
edhelasI'm not coming wih a proper solution here, just that I can't scale Pubsub for now
edhelasespecially because of this disco issue
HolgerMaybe. 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.
edhelasbut that's the same thing with disco overall :D XMPP is just not that good with discovery, too "raw"
edhelasindeed
Guushas left
Ge0rGhas left
alexishas left
alexishas joined
LNJhas left
Valerianhas joined
Dave Cridlandhas left
edhelasHolger what about filtering/ordering by https://xmpp.org/extensions/xep-0060.html#entity-metadata
edhelasI have to do a PR in that thing as well, to expose more metadata
edhelasincluding pubsub#access_model and pubsub#last_update
danielhas left
Dave Cridlandhas left
Guushas left
efrithas left
lumihas joined
jubalhhas left
Guushas left
efrithas joined
ThibGhas joined
SaltyBoneshas joined
ThibGhas joined
ralphmhas left
ralphmhas left
LNJhas left
Dave Cridlandhas left
alexishas left
ralphmhas left
goffihas joined
Dave Cridlandhas left
jubalhhas left
Guushas left
SaltyBoneshas left
Ge0rGhas left
ralphmLink 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.
ralphmGoing from Deferred to Deprecated doesn't make sense to me.
Anuhas joined
Link MauveI agree, but that rarely happens.
Link MauveOr at least not in a timely manner.
Ge0rGhas left
ralphmDeferred 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.
Dave Cridlandhas left
SaltyBoneshas joined
edhelasalso you cannot ask developpers to implement a new XEP, they are implementing it if they find it valuable
ralphmXEP-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.
ralphmedhelas: a new XEP is not Deferred
Guushas left
andyhas left
edhelassorry, defered
Guushas left
ralphmSure, people that have a particular use case might not care about the actual status.
alexishas joined
danielhas left
danielhas left
ralphmWe 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.
moparisthebesthas joined
Link Mauveedhelas, we make sure these developers will continue to implement deprecated things, by making experimental ones scary and never advancing them, and by deferring them.
ralphmTo be honest, the XHTML-IM spec should have a description of why it was deprecated.
Guushas left
moparisthebesthas joined
edhelaswhat is the state of bookmark2 by the way ?
ralphm(and probably also mark XEP-0393 as a successor if that was the intent of the Council)
Dave Cridlandhas left
danielhas left
Dave Cridlandhas left
Guushas left
Guushas left
ralphmI 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?
tahas left
UsLhas joined
danielhas left
alexishas left
alexishas joined
ralphmhas left
alexishas left
alexishas joined
alexishas left
Guushas left
danielhas left
Guushas left
alexishas joined
danielhas left
alexishas left
alexishas joined
Guushas left
Guushas left
Dave Cridlandhas left
danielhas left
ralphmhas left
alexishas left
alexishas joined
ralphmhas left
alexishas left
alexishas joined
ralphmhas left
Guushas left
alexishas left
alexishas joined
efrithas left
AnuFunny thing, what I find more difficult is keeping track of when the spec changes
AnuShort of being in these groups I don’t know how I would know that something I implemented years ago has been updated or changed
AnuWell that and someone telling me something is broken
MattJAre you on the standards mailing list?
AnuNo
MattJThat's the central place for notifications about updates
AnuI have been in the past but since I do stuff as a hobby more than professionally
AnuI’m often out of the loop or behind
alexishas left
alexishas joined
AnuAny other protocol has an overall version of the api
ZashWhat protocols?
MattJAnu, there was a proposal for that recently on the standards list ;)
AnuThere are many closed protocols that use xmpp as a backend but expose it as a rest Api
alexishas left
alexishas joined
AnuThey 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
andyhas joined
AnuThe largest closed garden messaging services are or started as xmpp servers with push support and rest interfaces
danielhas left
Guushas left
Guushas left
alexishas left
alexishas joined
SaltyBoneshas left
alexishas left
alexishas joined
alexishas left
alexishas joined
alexishas left
SaltyBoneshas joined
alexishas joined
alexishas left
alexishas joined
ralphmhas left
alexishas left
alexishas joined
alexishas left
alexishas joined
alexishas left
alexishas joined
AnuApi 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 .
AnuThere are a lot of xeps and they all look equally important
AnuBut in reality some are heavily supported and others aren’t
Valerianhas left
Valerianhas joined
Guushas left
Ge0rGAnu: XEP-0387 is supposed to provide an up-to-date overview of the most important ones for IM
Zashhas left
Ge0rGAnu: 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
Andrew Nenakhovhas joined
Kevhas left
Yagizahas left
danielhas left
MarandaRegarding 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.
edhelasMaranda I'm currently talking with order
edhelaswe maybe have an idea :) define two new XEPs Result Order Management and Result Filtering Management
moparisthebesthas joined
danielhas left
edhelasthe service expose trough the disco#info the field that you can order and filter on
edhelasand boom, you apply just RSM like things
edhelas*Holger
MarandaOrder?
Orderhas joined
HolgerYes, with me.
HolgerOh.
LNJhas left
HolgerSeems my client failed to change my nick to 'Order' before making that statement.
Zashhas left
Valerianhas left
Valerianhas joined
MarandaResult order management is needed for what beside the obvious?
HolgerReceived error packet [conflict] from <xsf@muc.xmpp.org/Order>
Zashhas joined
MarandaChanging order based on x?
MattJMultiple devices under the same nick
edhelasMaranda that's it
HolgerMattJ: Ah, right.
Guushas left
MarandaI have a Jappix dejavu for some reason.
Ge0rGMSN nicknames are a problem still.
HolgerTBH 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.
MarandaYes, agreed.
HolgerGe0rG: We have no problems, we have opportunities.
MarandaI came out with something even simpler than using DFs, but that's the idea.
Holger(Sorry already had a bullshit bingo meeting today.)
Ge0rGHolger: let's make an MVP!
MattJProsody trunk == your MVP
Ge0rGFrom MVP to ICO in only 0.5 Bitcoins!
Ge0rGA coworker of mine is quitting to do something with the blockchain. Let's see if I can talk him out of it again.
MarandaGe0rG I suggest just blocking him with a chain.
Ge0rGis that like clubbing him with books?
rionhas joined
MarandaOn the nearest lamp post
Guushas left
MarandaIrregardless 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
Maranda🤣
Ge0rGHm. https://wiki.xmpp.org/web/Special:Random is rather worthless because you always end up on random membership application pages.
Ge0rGMaranda: was that boy to be sold or to be rented out?
Maranda"Irregardless of the nature of the article" you know what to do with the "chain" and your colleague
Marandaprobably failed at some humor attempt
MarandaOr google failed bringing up a good piccie
Guushas left
Ge0rGHm. https://wiki.xmpp.org/web/Facebook links to a non-existent page.
MarandaGe0rG, more adapt http://www.mannequin-man.com/machinemart6.jpg
danielhas left
MarandaFor some reason the first results of "chained to a lamp post" all brought either bikes or stuff that is all but humouristical
alexishas joined
Ge0rGSo... 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
Maranda"Account joins all bookmarks on behalf of client"?
MarandaIs that still the bnc idea?
Ge0rGMaranda: yes
lskdjfhas joined
Ge0rGIt's a good, strong idea.
Guushas left
marmistrzhas left
danielhas left
HolgerIt's an opportunity.
MarandaQuestions... when "is it supposed to join" and "how long is it supposed to stay joined"
Guushas left
moparisthebesthow is the POC prosody module to do that working out?
Ge0rGMaranda: when bookmarks
Maranda"When bookmarked" and "for eternity from that" has its issues ™️
Ge0rGMaranda: I know. Tell the MIX.
Ge0rGMaranda: I would probably go with something like "at most N (=14) days after the last client disconnected"
Alexhas joined
Ge0rGBut obviously, having a zombie in a MUC is not desirable
moparisthebestthat'd just be an account/server setting
Ge0rGMaybe also "when the last client session is killed"
Maranda14 days on very busy room is a lot but still better than forever
ZashAnyone tested my minimix?
Ge0rGmoparisthebest: users won't be able to figure it out. Probably not even server admins
Tobiashttps://blog.torproject.org/sunsetting-tor-messenger what do they mean with centralized metadata problem? isn't it decentralized?
Kevhas joined
moparisthebestoh 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'
MarandaI think they just brought a random word to add between the last one and "problem"
MarandaBut that's me
mimi89999has left
mimi89999has left
mimi89999has joined
moparisthebestThe 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.
mimi89999has joined
mimi89999has joined
moparisthebestso they are just saying all of those are centralized (xmpp least of which, but still has a good amount of metadata)
ralphmhas left
mimi89999has left
mimi89999has joined
vanitasvitae> https://blog.torproject.org/sunsetting-tor-messenger what do they mean with centralized metadata problem? isn't it decentralized?
Iwas thinking the same.
Ge0rGvanitasvitae: it's more centralized than in p2p messengers
efrithas joined
moparisthebestin other words it is not https://en.wikipedia.org/wiki/TorChat
Marandamoparisthebest, 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?
la|r|mahas left
la|r|mahas joined
jubalhhas left
mimi89999has left
MarandaAka If you're so concerned, just go serverless and GTFO with it.
mimi89999has joined
moparisthebestI still think much can be done with XMPP towards the 'no metadata' goal, or at least 'minimal metadata'
KevSome things can, but it's hard to get away from an envelope, I think
Ge0rGIf you want E2EE and minimal meta-data, XMPP is just not the right protocol.
moparisthebestthe initial plan I have in my mind, in a 2 server scenario, prevents any 1 server from knowing the endpoints
danielhas left
Ge0rGmoparisthebest: you want to reinvent tor at the message routing layer.
jubalhhas joined
moparisthebestit's not actually that complicated, but perhaps that's a good summary
Valerianhas left
moparisthebestbasically 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
Ge0rGmoparisthebest: 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
moparisthebestyep, but we already have that with omemo and pgp so
Valerianhas joined
moparisthebestgoing with tor is already done with torchat, it doesn't give me all the nice things xmpp does though
Valerianhas left
Valerianhas joined
Ge0rGmoparisthebest: both OMEMO and PGP suck regarding identity management. There is no strong binding between your JID and your key.
Ge0rGmoparisthebest: you could do serverless XMPP between onion hosts.
moparisthebestsounds like it'd eat battery though
Ge0rGmoparisthebest: I'm not so sure. You need to get some tor routing DHT data, that's some hundred megs a week or so
moparisthebestone 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 ¯\_(ツ)_/¯ :)
danielhas left
MattJGe0rG, having no strong binding between your JID and your key is a bonus in the context of the metadata thing
MattJI could message you from a new random JID every day, but you would still know it was me
Ge0rGMattJ: except I would need to analyze your key to decrypt, and attackers could do so as well to identify you
moparisthebestonly the thing meant to decrypt it should be able to do that
KevGe0rG: unless it's sign then encrypt.
Ge0rGAnd how am I supposed to respond in this scheme?
KevYou don't bother, it was probably spam anyway :D
MarandaLol
MattJGe0rG, who is the attacker in that case?
moparisthebestin 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
MattJThe premise is that I can use a different server for each message if I wanted
andyhas left
Guushas left
MarandaCan you?
MarandaDXMPP!
Marandaisn't anymore certain how much of this discussion is serious and how much is sci-fi.
moparisthebestI 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
Guushas left
lumihas left
danielhas left
jubalhhas left
jjrhhas left
Guushas left
Valerianhas left
efrithas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Dave Cridlandhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
jonaswhas left
Yagizahas left
danielhas left
jerehas joined
Seve/SouLhas joined
jubalhhas joined
efrithas joined
Yagizahas joined
j.rhas joined
ThibGhas joined
ThibGhas joined
Dave Cridlandhas left
jjrhhas left
jjrhhas left
Dave Cridlandhas left
ralphmhas left
Dave Cridlandhas left
winfriedhas joined
SamWhitedhas left
danielhas left
Dave Cridlandmoparisthebest, 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.
Dave Cridlandmoparisthebest, 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.
moparisthebestnot from the server though Dave Cridland ?
moparisthebestbut yes, you'd have to be careful not to use bookmarks/blocklists/etc when hiding metadata from your server
ralphmhas joined
jjrhhas left
alexishas left
jjrhhas left
ralphmhas joined
Dave Cridlandmoparisthebest, 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.
ZashThat's not going to scale tho
danielhas left
alexishas joined
MattJEvery 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...
Ge0rGMattJ: and then they talk about random stuff in that MUC.
MattJWhat else do you talk about after going to all that effort?
Ge0rGthat reminds me of amateur radio. You build complicated devices to talk to other nerds about the complicated devices you built.
MarandaTacos.
Ge0rGdevices, tacos and knee implants.
MarandaI'd need a shoulder implant more atm probably :P
ZashSounds like how GNU Social was a social network for talking about GNU Social
Ge0rGI need a gatling gun implant.
ZashOr how 3D printers are devices for producing parts for 3D printers
Tobiashas joined
moparisthebestDave Cridland, xmpp needs only certain parts for routing, not all the parts it has now
moparisthebestit just needs the last and next hop, not both endpoints
Dave Cridlandmoparisthebest, Sure. That's basically Tor, right?
danielhas left
moparisthebestit's xmpp just with an extra bit
moparisthebestbut, kinda
la|r|mahas joined
alexishas left
alexishas joined
danielhas left
MarandaI'm dead curious to see the practical result.
Guushas left
alexishas left
danielhas left
alexishas joined
Guushas left
alexishas left
alexishas joined
Guushas left
efrithas left
Guushas left
remkohas left
remkohas left
andyhas joined
lovetoxhas joined
Guushas left
Guushas left
Guushas left
Marandahas joined
danielhas left
tahas joined
jjrhhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Valerianhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
danielhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
ludohas left
ludohas joined
danielhas left
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas joined
danielhas left
ralphmhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
SamWhitedhas left
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas left
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
blablahas joined
Ge0rGhas left
Valerianhas joined
Dave Cridlandhas left
marchas joined
Guushas left
Dave Cridlandhas left
Dave Cridlandhas left
Guushas left
Marandahas left
Dave Cridlandhas left
Dave Cridlandhas left
Martinhas left
SamWhitedhas left
Martinhas joined
Martinhas left
danielhas left
winfriedhas left
Guushas left
SamWhitedhas left
jubalhhas left
Valerianhas left
Valerianhas joined
danielhas left
marchas left
remkohas left
Dave Cridlandhas left
Valerianhas left
Valerianhas joined
Nekithas left
ralphmhas joined
Steve Killehas left
Nekithas joined
Steve Killehas left
danielhas left
Steve Killehas joined
SaltyBoneshas left
Dave Cridlandhas left
jerehas joined
Alexhas left
j.rhas left
jerehas joined
jjrhis there a xep or is anyone working on one for emoji reactions?
SamWhitedThose may give you the building blocks to build such a system, but I don't think there's anything standardizing that feature in particular.
SamWhitedhas left
blablahas left
SamWhited(and I'm not aware of anyone working on it)
j.rhas joined
jjrhbuddy sent me https://api.slack.com/docs/message-buttons
jjrhwhich is a interesting feature
danielhas left
KevSamWhited: We're not quite there yet, but we're starting to build up References stuff.
marchas joined
KevThe issue with emoji reactions is that while sending them is straightforward, dealing with them very much isn't.
SamWhitedhas left
KevWe 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.
ZashSo References is going to do everything?
KevDepends what 'everything' is.
alexishas left
KevI don't see a reason not to use References as the framework for everything that's a reference.
alexishas joined
KevBut I'm not intending squeezing URL references, emoji reactions, quotes, etc. all into the one XEP.
ZashI mean, it looks like References and Attaching have some overlap
KevThey do, yeah.
Chobbeshas joined
jubalhhas joined
danielhas left
jjrhI have heard from multiple people that emoji reactions are the killer feature of slack
moparisthebestI still don't get what they give you over a well timed
jjrhpeople use them for stuff like "do we have quorum for the XSF boardmeeting?" and you do +1 or whatever
moparisthebest>:)
moparisthebestor whatever
ZashI've learned to take what people say the killer feature is with some salt.
moparisthebestbut I guess I'm oldschool or something
jjrhwell 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
ChobbesI 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.
KevZash: On the one hand, yes.
moparisthebestseems like it'd be useful on something like twitter, not so much instant messaging
KevOn the other, people really do get these little features into their workflow and they add value.
SaltyBoneshas left
jjrhnot saying it's THE killer feature - but it's a feature I hear - to my surprise - a lot of people use.
KevI don't use them as much as some folks, but it's useful.
Valerianhas left
Valerianhas joined
ZashAlso, people tend to differ on which feature is the killer feature. Everyone has their own favorite.
KevAnd one message with "30👍" beats a message with 30 replies each just saying 'great' or something by a long margin.
Kevhas left
SaltyBoneshas left
Chobbesmoparisthebest, 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.
ZashLast week it was stickers. XMPP can't succeed without stickers! It's the killer feature!
ZashBefore that it was something else.
jjrhwhat are stickers?
danielI'd certainly implement it if someone writes a xep
ZashExactly.
Zashdaniel: Or you could implement it and XEP-ify what you did.
Nekithas left
Kevdaniel: It's one of the oh-so-many things on my list.
ZashThe age old question, which comes first, implementation or specification :)
KevMAM is the real killer for it, otherwise it's trivial.
ZashKev: The problem you talk of, it's basically the same as with corrections, right?
KevAnd receipts.
KevYes.
KevBoth 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.
ZashAka "graph-like queries on log-style data is messy"
SamWhitedhas left
KevBecause message logs are actually message forests where each IM message is the root of a tree with leaves of emoji, corrections, receipts, URLs, ...
KevThankfully not at all messy.
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas left
jubalhhas joined
SaltyBoneshas joined
ralphmhas left
danielhas left
MattJEncode messages into a DAG structure, switch to JSON and transport them over HTTP
ralphmhas joined
Andrew Nenakhovhas left
SamWhitedhas left
ibikkhas joined
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
ralphmhas left
ralphmhas joined
waqashas joined
Guushas left
Valerianhas left
Valerianhas joined
Yagizahas left
Guushas left
danielhas left
Guushas left
Valerianhas left
Valerianhas joined
waqashas left
ralphmhas joined
waqashas joined
ibikkhas joined
Guushas left
Guushas left
Guushas left
Guushas left
Ge0rGhttps://github.com/jabbercat/jabbercat/issues/80 proto XEP for reactions be here
danielhas left
Guushas left
Ge0rGjjrh: ^
ThibGhas joined
waqashas left
Guushas left
Guushas left
ludohas left
ludohas joined
marchas left
Guushas left
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
Ge0rGpep.: what if you make a happy white and a sad black Emoji (slack supports that)? Is that Racial Segregation?