without the "node" attribute, then I can paginate on those nodes
Marandaalready spoke about the topic, "just.. No"
Maranda
That's more about adding some result filtering option to disco#items queries (and something simpler than having to implement connection nodes) imho
Maranda
s/connection/collection/
MattJ
edhelas, indeed, aren't you just looking for RSM on disco#items? Which is one of the things RSM was created for
Yagizahas joined
Kev
But no-one* implements, unfortunately.
edhelas
I'd like to also order
Kev
[* I've not seen it in the wild, in any case]
MattJwaits for the *
MattJ
Aww
edhelas
RSM would be nice for pagination indeed
MattJ
I was hoping for *except we almost have an implementation in Swift
Kev
We've got RSM in Swift, but not plumbed into disco.
edhelas
*soon to be released
edhelas
also filtering
edhelas
but 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
edhelas
and I want only the top 50 ones
ThibGhas joined
alexishas left
Ge0rGhas left
Alexhas joined
winfriedhas left
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
Bunneh
Maranda: Service Discovery (Standards Track, Final, 2017-10-03)
See: https://xmpp.org/extensions/xep-0030.html
Maranda
I suppose "hierarchies"?
Kev
You could use disco nodes for the filtering, and RSM on that :)
edhelas
Kev what do you mean ?
Alexhas left
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.
tahas left
edhelas
I don't see how you can do that
alexishas joined
danielhas left
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
Maranda
Not the client retrieving everything and then filter
Kev
Indeed.
Valerianhas left
Kev
I repeat, you could just define a syntax for using nodes as a filter.
Kev
)
Kev
:)
Valerianhas joined
edhelas
I know that there's the pubsub#type attribute in Pubsub
Valerianhas left
Valerianhas joined
Valerianhas left
j.rhas joined
efrithas joined
Maranda
I guess you could arbitrarily use type or something else, but whatever needs implementation both sides
danielhas left
Maranda
Aka hax
danielhas joined
winfriedhas joined
Maranda
Something more definite in the spec itself would be better imho (but then that would fall into the same issues)
Valerianhas joined
edhelas
yeah
edhelas
I'm kinda lost
andyhas left
Valerianhas left
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
Maranda
s/hierarchy/branch/
Maranda
As long as not using collections which is overly convoluted
edhelas
do we have one Pubsub Collection implementation in the wild that is actuavelly used ?
Holger
ejabberd has code for it.
edhelas
I'm still finishing the 0060 pubsub implementation in ejabberd
Holger
No idea whether it's actually used by anyone :-)
edhelas
Holger as far as I saw, it's far from be done
Holger
Ah. No idea.
Maranda
Problem here we have 3 xeps to deal with disco, pubsub and microblogging
ralphm
I know it is used, but personally I think the current spec is not great. Except, maybe, the root node.
Maranda
😎
Andrew Nenakhovhas left
edhelas
Maranda it's more than Pubsub
edhelas
again, how can I discover conferences on my own server without listing 10K conferences from the service ?
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.
Maranda
I said "disco, pubsub and microblogging"...
goffihas left
edhelas
ah yeah sorry
edhelas
ralphm maybe we can deprecate Collection ?
ralphm
I guess we could, but who would benefit from this exactly?
edhelas
who is benefiting from it actually ?
ralphm
The specification is already deferred
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.
Andrew Nenakhovhas joined
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
edhelas
*it
andyhas joined
ralphm
I.e. you can't go to deferred without going to Draft, first.
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
edhelas
then a client that want to explore the network will be able to grab lots of interesting data quickly
edhelas
and not doing recursive exploration, loading entire dump of nodes and exploring each of thems
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.
edhelas
yes
ralphm
I like doing nothing and achieve results :-D
edhelas
MAM got a lot of nice features, including filtering on results, pagination
edhelas
too bad it's called "message archive"
edhelas
because it could be used for many other use cases
edhelas
like discovery
Holger
Well the pagination is 0059, it's just the filtering syntax you're missing, no?
edhelas
as well
Holger
Or sorting, which MAM also doesn't have.
edhelas
yup :D
Holger
I.e. "sort by number of participants/subscribers" or so.
edhelas
both 3
Holger
So I don't quite buy "MAM is perfect just has the wrong name" :-P
Holger
I totally see your use case and would think this just[tm] needs a bit new syntax.
tuxhas joined
edhelas
or we can revive SQL over XMPP
edhelas---> []
Ge0rG
edhelas: 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
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
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.
edhelas
also MAM can then reuse that, I mean, in ejabberd MAM is basically querying the archives table :p
alexishas joined
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.
tahas joined
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"
edhelas
Holger yeah maybe
winfriedhas left
edhelas
I'm not coming wih a proper solution here, just that I can't scale Pubsub for now
edhelas
especially because of this disco issue
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.
edhelas
but that's the same thing with disco overall :D XMPP is just not that good with discovery, too "raw"
edhelas
indeed
Guushas left
Ge0rGhas left
alexishas left
alexishas joined
LNJhas left
Valerianhas joined
Dave Cridlandhas left
edhelas
Holger what about filtering/ordering by https://xmpp.org/extensions/xep-0060.html#entity-metadata
edhelas
I have to do a PR in that thing as well, to expose more metadata
edhelas
including 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
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.
ralphm
Going from Deferred to Deprecated doesn't make sense to me.
Anuhas joined
Link Mauve
I agree, but that rarely happens.
Link Mauve
Or at least not in a timely manner.
Ge0rGhas left
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.
Dave Cridlandhas left
SaltyBoneshas joined
edhelas
also you cannot ask developpers to implement a new XEP, they are implementing it if they find it valuable
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.
ralphm
edhelas: a new XEP is not Deferred
Guushas left
andyhas left
edhelas
sorry, defered
Guushas left
ralphm
Sure, people that have a particular use case might not care about the actual status.
alexishas joined
danielhas left
danielhas left
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.
moparisthebesthas joined
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.
ralphm
To be honest, the XHTML-IM spec should have a description of why it was deprecated.
Guushas left
moparisthebesthas joined
edhelas
what 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
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?
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
Anu
Funny thing, what I find more difficult is keeping track of when the spec changes
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
Anu
Well that and someone telling me something is broken
MattJ
Are you on the standards mailing list?
Anu
No
MattJ
That's the central place for notifications about updates
Anu
I have been in the past but since I do stuff as a hobby more than professionally
Anu
I’m often out of the loop or behind
alexishas left
alexishas joined
Anu
Any other protocol has an overall version of the api
Zash
What protocols?
MattJ
Anu, there was a proposal for that recently on the standards list ;)
Anu
There are many closed protocols that use xmpp as a backend but expose it as a rest Api
alexishas left
alexishas joined
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
andyhas joined
Anu
The 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
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 .
Anu
There are a lot of xeps and they all look equally important
Anu
But in reality some are heavily supported and others aren’t
Valerianhas left
Valerianhas joined
Guushas left
Ge0rG
Anu: XEP-0387 is supposed to provide an up-to-date overview of the most important ones for IM
Zashhas left
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
Andrew Nenakhovhas joined
Kevhas left
Yagizahas left
danielhas left
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.
edhelas
Maranda I'm currently talking with order
edhelas
we maybe have an idea :) define two new XEPs Result Order Management and Result Filtering Management
moparisthebesthas joined
danielhas left
edhelas
the service expose trough the disco#info the field that you can order and filter on
edhelas
and boom, you apply just RSM like things
edhelas
*Holger
Maranda
Order?
Orderhas joined
Holger
Yes, with me.
Holger
Oh.
LNJhas left
Holger
Seems my client failed to change my nick to 'Order' before making that statement.
Zashhas left
Valerianhas left
Valerianhas joined
Maranda
Result order management is needed for what beside the obvious?
Holger
Received error packet [conflict] from <xsf@muc.xmpp.org/Order>
Zashhas joined
Maranda
Changing order based on x?
MattJ
Multiple devices under the same nick
edhelas
Maranda that's it
Holger
MattJ: Ah, right.
Guushas left
Maranda
I have a Jappix dejavu for some reason.
Ge0rG
MSN nicknames are a problem still.
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.
Maranda
Yes, agreed.
Holger
Ge0rG: We have no problems, we have opportunities.
Maranda
I came out with something even simpler than using DFs, but that's the idea.
Holger
(Sorry already had a bullshit bingo meeting today.)
Ge0rG
Holger: let's make an MVP!
MattJ
Prosody trunk == your MVP
Ge0rG
From MVP to ICO in only 0.5 Bitcoins!
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.
Maranda
Ge0rG I suggest just blocking him with a chain.
Ge0rG
is that like clubbing him with books?
rionhas joined
Maranda
On the nearest lamp post
Guushas left
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
Maranda
🤣
Ge0rG
Hm. https://wiki.xmpp.org/web/Special:Random is rather worthless because you always end up on random membership application pages.
Ge0rG
Maranda: 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
Maranda
Or google failed bringing up a good piccie
Guushas left
Ge0rG
Hm. https://wiki.xmpp.org/web/Facebook links to a non-existent page.
Maranda
Ge0rG, more adapt http://www.mannequin-man.com/machinemart6.jpg
danielhas left
Maranda
For some reason the first results of "chained to a lamp post" all brought either bikes or stuff that is all but humouristical
alexishas joined
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
Maranda
"Account joins all bookmarks on behalf of client"?
Maranda
Is that still the bnc idea?
Ge0rG
Maranda: yes
lskdjfhas joined
Ge0rG
It's a good, strong idea.
Guushas left
marmistrzhas left
danielhas left
Holger
It's an opportunity.
Maranda
Questions... when "is it supposed to join" and "how long is it supposed to stay joined"
Guushas left
moparisthebest
how is the POC prosody module to do that working out?
Ge0rG
Maranda: when bookmarks
Maranda
"When bookmarked" and "for eternity from that" has its issues ™️
Ge0rG
Maranda: I know. Tell the MIX.
Ge0rG
Maranda: I would probably go with something like "at most N (=14) days after the last client disconnected"
Alexhas joined
Ge0rG
But obviously, having a zombie in a MUC is not desirable
moparisthebest
that'd just be an account/server setting
Ge0rG
Maybe also "when the last client session is killed"
Maranda
14 days on very busy room is a lot but still better than forever
Zash
Anyone tested my minimix?
Ge0rG
moparisthebest: users won't be able to figure it out. Probably not even server admins
marmistrzhas left
Ge0rG
Zash: tell us how
Zash
Ge0rG: I'm sure I put it in prosody-modules
danielhas left
Ge0rG
Zash: I'm not sure you told us that before
Ge0rG
so https://modules.prosody.im/mod_minimix.html
winfriedhas left
Yagizahas joined
Tobias
https://blog.torproject.org/sunsetting-tor-messenger what do they mean with centralized metadata problem? isn't it decentralized?
Kevhas joined
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'
Maranda
I think they just brought a random word to add between the last one and "problem"
Maranda
But that's me
mimi89999has left
mimi89999has left
mimi89999has joined
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.
mimi89999has joined
mimi89999has joined
moparisthebest
so 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.
Ge0rG
vanitasvitae: it's more centralized than in p2p messengers
efrithas joined
moparisthebest
in other words it is not https://en.wikipedia.org/wiki/TorChat
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?
la|r|mahas left
la|r|mahas joined
jubalhhas left
mimi89999has left
Maranda
Aka If you're so concerned, just go serverless and GTFO with it.
mimi89999has joined
moparisthebest
I still think much can be done with XMPP towards the 'no metadata' goal, or at least 'minimal metadata'
Kev
Some things can, but it's hard to get away from an envelope, I think
Ge0rG
If you want E2EE and minimal meta-data, XMPP is just not the right protocol.
moparisthebest
the initial plan I have in my mind, in a 2 server scenario, prevents any 1 server from knowing the endpoints
danielhas left
Ge0rG
moparisthebest: you want to reinvent tor at the message routing layer.
jubalhhas joined
moparisthebest
it's not actually that complicated, but perhaps that's a good summary
Valerianhas left
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
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
moparisthebest
yep, but we already have that with omemo and pgp so
Valerianhas joined
moparisthebest
going with tor is already done with torchat, it doesn't give me all the nice things xmpp does though
Valerianhas left
Valerianhas joined
Ge0rG
moparisthebest: both OMEMO and PGP suck regarding identity management. There is no strong binding between your JID and your key.
Ge0rG
moparisthebest: you could do serverless XMPP between onion hosts.
moparisthebest
sounds like it'd eat battery though
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
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 ¯\_(ツ)_/¯ :)
danielhas left
MattJ
Ge0rG, having no strong binding between your JID and your key is a bonus in the context of the metadata thing
MattJ
I could message you from a new random JID every day, but you would still know it was me
Ge0rG
MattJ: except I would need to analyze your key to decrypt, and attackers could do so as well to identify you
moparisthebest
only the thing meant to decrypt it should be able to do that
Kev
Ge0rG: unless it's sign then encrypt.
Ge0rG
And how am I supposed to respond in this scheme?
Kev
You don't bother, it was probably spam anyway :D
Maranda
Lol
MattJ
Ge0rG, who is the attacker in that case?
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
MattJ
The premise is that I can use a different server for each message if I wanted
andyhas left
Guushas left
Maranda
Can you?
Maranda
DXMPP!
Marandaisn't anymore certain how much of this discussion is serious and how much is sci-fi.
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
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 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.
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.
moparisthebest
not from the server though Dave Cridland ?
moparisthebest
but 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 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.
Zash
That's not going to scale tho
danielhas left
alexishas joined
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...
Ge0rG
MattJ: and then they talk about random stuff in that MUC.
MattJ
What else do you talk about after going to all that effort?
Ge0rG
that reminds me of amateur radio. You build complicated devices to talk to other nerds about the complicated devices you built.
Maranda
Tacos.
Ge0rG
devices, tacos and knee implants.
Maranda
I'd need a shoulder implant more atm probably :P
Zash
Sounds like how GNU Social was a social network for talking about GNU Social
Ge0rG
I need a gatling gun implant.
Zash
Or how 3D printers are devices for producing parts for 3D printers
Tobiashas joined
moparisthebest
Dave Cridland, xmpp needs only certain parts for routing, not all the parts it has now
moparisthebest
it just needs the last and next hop, not both endpoints
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.
SamWhitedhas left
blablahas left
SamWhited
(and I'm not aware of anyone working on it)
j.rhas joined
jjrh
buddy sent me https://api.slack.com/docs/message-buttons
jjrh
which is a interesting feature
danielhas left
Kev
SamWhited: We're not quite there yet, but we're starting to build up References stuff.
marchas joined
Kev
The issue with emoji reactions is that while sending them is straightforward, dealing with them very much isn't.
SamWhitedhas left
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.
Zash
So References is going to do everything?
Kev
Depends what 'everything' is.
alexishas left
Kev
I don't see a reason not to use References as the framework for everything that's a reference.
alexishas joined
Kev
But I'm not intending squeezing URL references, emoji reactions, quotes, etc. all into the one XEP.
Zash
I mean, it looks like References and Attaching have some overlap
Kev
They do, yeah.
Chobbeshas joined
jubalhhas joined
danielhas left
jjrh
I have heard from multiple people that emoji reactions are the killer feature of slack
moparisthebest
I still don't get what they give you over a well timed
jjrh
people use them for stuff like "do we have quorum for the XSF boardmeeting?" and you do +1 or whatever
moparisthebest
>:)
moparisthebest
or whatever
Zash
I've learned to take what people say the killer feature is with some salt.
moparisthebest
but I guess I'm oldschool or something
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
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.
Kev
Zash: On the one hand, yes.
moparisthebest
seems like it'd be useful on something like twitter, not so much instant messaging
Kev
On the other, people really do get these little features into their workflow and they add value.
SaltyBoneshas left
jjrh
not saying it's THE killer feature - but it's a feature I hear - to my surprise - a lot of people use.
Kev
I don't use them as much as some folks, but it's useful.
Valerianhas left
Valerianhas joined
Zash
Also, people tend to differ on which feature is the killer feature. Everyone has their own favorite.
Kev
And one message with "30👍" beats a message with 30 replies each just saying 'great' or something by a long margin.
Kevhas left
SaltyBoneshas left
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.
Zash
Last week it was stickers. XMPP can't succeed without stickers! It's the killer feature!
Zash
Before that it was something else.
jjrh
what are stickers?
daniel
I'd certainly implement it if someone writes a xep
Zash
Exactly.
Zash
daniel: Or you could implement it and XEP-ify what you did.
Nekithas left
Kev
daniel: It's one of the oh-so-many things on my list.
Zash
The age old question, which comes first, implementation or specification :)
Kev
MAM is the real killer for it, otherwise it's trivial.
Zash
Kev: The problem you talk of, it's basically the same as with corrections, right?
Kev
And receipts.
Kev
Yes.
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.
Zash
Aka "graph-like queries on log-style data is messy"
SamWhitedhas left
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, ...
Kev
Thankfully not at all messy.
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas left
jubalhhas joined
SaltyBoneshas joined
ralphmhas left
danielhas left
MattJ
Encode 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
Ge0rG
https://github.com/jabbercat/jabbercat/issues/80 proto XEP for reactions be here
danielhas left
Guushas left
Ge0rG
jjrh: ^
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
Ge0rG
pep.: what if you make a happy white and a sad black Emoji (slack supports that)? Is that Racial Segregation?