moparisthebestDo any servers support https://xmpp.org/extensions/xep-0078.html anymore?
andyhas left
Alexhas left
moparisthebestOr might it be worth resurrecting? Since TLS is required and everyone (https world) agrees basic auth is fine, and it doesn't suffer from the "never upgradeable" problems sasl does?
Ellenor Maliksasl is downgrade resistant
moparisthebestAnd upgrade proof
archas joined
karoshihas left
dwdmoparisthebest, You can get the same effect as XEP-0078 with PLAIN, and essentially the same speed with SASL2, though.
matkorhas left
dwdmoparisthebest, And you get to choose more secure methods than PLAIN, as well.
moparisthebestI'm not clear on what those are, I know about "channel binding" for instance, and iirc it's been broken before and such, but assuming not who cares anyway
moparisthebestIf every http application ever can live without it, what's the point
archas left
archas joined
moparisthebestAgain, I understand not sending something plaintext across the network that can be used to login as you was absolutely critical when XMPP was written, TLS wasn't the norm then
moparisthebestIs it valuable in a world where everything is TLS though?
mukt2has joined
dwdHTTP applications often use OAuth, which can be done over SASL but not XEP-0078, for example.
moparisthebestThat's normally when you authenticate with a 3rd party service though right?
moparisthebestLike, sign into this site with your GitHub account?
moparisthebestDoes anything in XMPP do that?
dwdYes. But that doesn't matter - point is that SASL is extensible, whereas XEP-0078 isn't.
dwdAnd certainly some deployments seem to like having channel binding around, or not having plaintext password equivalents on the wire even with TLS in play.
Ellenor Malikmoparisthebest: SASL is the pinnacle
moparisthebestOh I get it's more extensible, it just seems 99% of the time the extra complexity and RTTs is not desirable
matkorhas joined
moparisthebestSeems like 0078 should be the norm and sasl the exception nowadays I'm saying?
moparisthebestMy impression is this situation is similar to Direct TLS vs STARTLS
mimi89999has left
mimi89999has joined
archas left
archas joined
mimi89999has left
mimi89999has joined
archas left
archas joined
lskdjfhas left
mimi89999has left
mimi89999has joined
mimi89999has left
mimi89999has joined
mimi89999has left
mimi89999has joined
lskdjfhas joined
lskdjfhas left
mukt2has left
andrey.ghas left
pdurbinhas joined
adiaholichas joined
Maxhas left
pdurbinhas left
Maxhas joined
mukt2has joined
Yagizahas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
archas left
archas joined
pdurbinhas joined
archas left
archas joined
pdurbinhas left
mukt2has left
Nekithas joined
adiaholichas left
karoshihas joined
andyhas joined
adiaholichas joined
lorddavidiiihas joined
andrey.ghas joined
serge90has left
Maxhas left
Maxhas joined
Tobiashas joined
mukt2has joined
paulhas joined
pdurbinhas joined
LNJhas joined
serge90has joined
LNJhas left
LNJhas joined
LNJhas left
LNJhas joined
mukt2has left
pdurbinhas left
archas left
archas joined
j.rhas left
mukt2has joined
debxwoodyhas joined
mukt2has left
j.rhas joined
mukt2has joined
waqashas left
debxwoodyhas left
adiaholichas left
adiaholichas joined
mukt2has left
serge90has left
flowmoparisthebest, I think SASL PLAIN is the same (or at least close to xep78) in terms of complexity and round trips
nyco-2has joined
nyco-2has left
mimi89999has left
nyco-2has joined
mimi89999has joined
serge90has joined
flowdwd, what's the benefit, besides feature discovery maybe, of "simple json" compared to xep335?
flowand will I find an answer ot this question by carefully reading the simple json XEP?
dwdI think so. How would a developer go about using 335? Would it involve more code than simple json?
dwdThe comparison isn't between simple json and raw 335, it's between simple json and stuffing json in directly into message bodies.
ellenorhas left
Ellenor Malikhas left
sonnyhas joined
ellenorhas joined
Ellenor Malikhas joined
mukt2has joined
adiaholichas left
adiaholichas joined
emushas joined
lorddavidiiihas left
lorddavidiiihas joined
andrey.ghas left
mukt2has left
mukt2has joined
DanielIsn't the comparison between stuffing json anywhere and explaining people what the x in xmpp stands for?
Marchas left
Marchas joined
goffihas joined
dwdPretty much.
mukt2has left
dwdBut I do understand that "Here is a protocol framework. Now off you go and design a protocol and implement it in multiple libraries" is quite a steep learning curve.
Dele Olajidehas joined
Ge0rGHTTP REST is even less than a protocol framework.
Ge0rGstill isn't over that app downloading 780KB of HTML from Google Play on each launch just to check if it's up-to-date.
dwdGe0rG, Yes, but you just stuff JSON into named endpoints and you're done.
dwdGe0rG, And moreover, even if you do download 780k, it won't damage the network. Whereas stuffing JSON into <body/> does, since naive clients can't be used anymore.
Ge0rGLeague of Legends used to stuff XML into the body, which of course was encoded.
mukt2has joined
dwdNovel, at least.
Ge0rGI think it's been in use a decade ago.
Ge0rG> Release: October 27, 2009
mukt2has left
goffihas left
goffihas joined
goffihas left
goffihas joined
Maxhas left
Maxhas joined
DebXWoodyhas left
Dele Olajidehas left
Dele Olajidehas joined
mimi89999has left
Alexhas joined
mukt2has joined
lorddavidiiihas left
Alexhas left
Alexhas joined
lorddavidiiihas joined
Alexhas left
Alexhas joined
Alexhas left
Alexhas joined
Alexhas left
DebXWoodyhas joined
mukt2has left
Alexhas joined
Dele Olajidehas left
mukt2has joined
mimi89999has joined
archas left
archas joined
Dele Olajidehas joined
goffihas left
nyco-2has left
nyco-2has joined
nyco-2has left
nyco-2has joined
goffihas joined
APachhas left
larmahas left
ralphmGe0rG, there's no last-modified/etag check upon retrieval?
lskdjfhas joined
Ge0rGralphm: the code is straight from https://stackoverflow.com/a/36509726/539443
Ge0rGIt's surprising that almost none of the http client libraries actually supports local caching
Ge0rGso you end up doing it manually, badly. if at all
DebXWoodyhas left
ralphmThat's pretty terrible indeed.
larmahas joined
ralphmI.e. I can't get over how little people know about stuff like this, and always get this wrong.
ralphmEspecially when people were still doing RSS aggregators.
Ge0rGHey, encoding a bet on Google not changing their HTML into your app is also a rather dumb decision
APachhas joined
Ge0rGLuckily, the app's API designers were competent at least.
ralphmI guess
nyco-2has left
nyco-2has joined
DebXWoodyhas joined
mukt2has left
mukt2has joined
nyco-2has left
nyco-2has joined
larmahas left
andrey.ghas joined
Maxhas left
Maxhas joined
larmahas joined
MattJshould iq type="get" *never* have side-effects?
MattJBecause we have an example of such in... RFC 6121
MattJRequesting the roster "subscribes" you to roster pushes
ZashWat
larmavanitasvitae: do XMPP libraries typically provide APIs to easily send arbitrary XML? I was under the assumption they don't make it that easy
MattJ> If a connected resource or available resource requests the roster, it is referred to as an "interested resource". The server MUST send roster pushes to all interested resources.
MattJlarma, totally depends on the library
vanitasvitaelarma: in Smack you could do it fairly easily I think
MattJSome are high level, and try to hide everything from you, some are low level and offer barely any XMPP stuff - some fall in between (you could say they fail at both)
archas left
archas joined
vanitasvitaeYeah, in Smack you can parse the XML into a "StandardExtensionElement" and append that to your messages.
larmavanitasvitae: that isn't what I would call an easy API
vanitasvitae¯\_(ツ)_/¯
vanitasvitaePR welcome :P
pep.MattJ, ugh (re roster). I can see why that's been done but that seems like breaking some assumptions indeed
larmaI just wonder how we are considering to add stream.send_json(to, json), when we don't have stream.send_xml(to, XML)
Alexhas left
MattJIt seems obvious that 99% of the time if you request the information you are also interested in changes to that information
Alexhas joined
pep.That seems like a bold assumption to make. Especially since we have mechanisms to say we're interested in the data
Alexhas left
Link Mauvepep., they wouldn’t be atomic.
Alexhas joined
pep.what do you mean
Link Mauvepep., caps to your server may be known to your server long after you’ve requested the roster.
Link MauveIn the meantime, you would miss roster pushes.
pep.Seems like an edge-case no? Or maybe there's something missing for this kind of case (subscribing to data around bind)
MattJAtomic get-and-subscribe is quite an important operation to have
mukt2has left
pep.Yes but it this really what we want for iq type="get"? :x
pep.Does that mean because I've requested somebody's version I want to know now everytime they change
mukt2has joined
MattJThe XEP doesn't specify that behaviour, so no, it doesn't mean that
MattJIt means instead that you have to poll if you ever do want that :)
lorddavidiiihas left
lorddavidiiihas joined
dwdlarma, Most libraries let you send/receive arbitrary XML, in various ways that are individually reasonably sane. The problem is that they're all radically different from one another and involve a lot of implied knowledge to use well.
larmaYeah, but we are we then not unifying/easying the use of custom XML in XMPP and instead only unify/ease the use of custom JSON in XMPP?
larmaYeah, but why are we then not unifying/easying the use of custom XML in XMPP and instead only unify/ease the use of custom JSON in XMPP?
dwdlarma, I can't think of a way to do that without essentially distilling it into "learn XMPP really good".
mtavareshas left
dwdlarma, Don't get me wrong; that's my preferred solution. I just think it's impractical.
Dele Olajidehas left
larmaWhy?
larmaAlso, why is it required to learn xmpp really good for that?
Danieldoes anyone know of a thing that is an xmpp client on one end and a rest api on the other?
Danielwith rest calls to send; and where you can put in (http) callbacks for notifications
Danielbot developers these days can’t be bothered to connect to anything not http
dwdDaniel, Like the Prosody API, or XMPP-FTW?
Danielmaybe. let me take a look
dwdlarma, I don't know where you'd start with trying to create a generic API. I got a lot of pushback for including the sketch in the original UDT.
dwdDaniel, I don't know how maintained XMPP-FTW is, now. At one point it was heavily worked on by Lloyd, but he's moved onto other things and I don't know anyone else picked it up. It was, at one point, looking as if it'd merge the XML <-> JSON translations bits with stanza.io^Wjs.
larmadwd: when searching for how to do custom XML in smack I found https://stackoverflow.com/questions/6387947/how-to-send-custom-xml-packet-using-javas-smack-api which basically says, "here is how you, but don't do it"
larmaIt already starts with the requirement to define a namespace...
Danieldwd, yeah; probably something like mod_rest for prosody. probably a little less generic; and kinda scoped to one user (callbacks for just one user; not all users)
larmadwd: can we at least agree that it should just be sending strings instead of json so that it can be any notation, or just strings, or base64 encoded binary, or ... Also that would allow libraries to not care about json at all (the current proposal requires libraries implementing it to at least include a json validator)
ZashDaniel: Use case? Bots or something?
DanielZash: yes bots
ZashI'd like mod_rest to support that. Currently it's probably awkward unless you give the bot an entire domain
DanielYes. Mod_rest isn't too far of from what we want to do. Except that. And except that we have only limited control over the server (don't ask) and are not running prosody
dwdhas left
LNJhas left
LNJhas joined
moparisthebestthat is generally my complaint with about every XMPP library I've ever used, they all make you jump through a series of hoops when I just want to send a String
ZashDaniel: mod_component_client! (Connect Prosody as a 114 component to another XMPP server)
Link MauveDaniel, you also have mod_slack_webhooks, which AIUI lets Slack bots connect to Prosody.
Zashmoparisthebest: That's a good thing IMO. Pain to enforce well-formedness and stanza counting for 198 if you just get strings.
DanielLink Mauve: oh that might be interesting
ZashWe have a ton of variations of this, sending messages via http. mod_rest is kinda meant to be the one that does it all
ZashI wonder i f this is something we wanna standardize tho, "HTTP based component/bot interface"
Link MauveThis has been proposed at Summit, but other things took priority.
moparisthebestZash, so if you are building a client or, something serious it's a good thing, if you just want to experiment quickly not so much
moparisthebestI tend to think they should be built in layers, bottom just deals with strings, slightly higher XML, over that you have your normal API that helps with things
Link MauveOh, you actually meant printf XML?
pep.larma, yeah I tend to agree with that. since it's really application specific I'm not sure why we'd restrict it to JSON, not sure why the library would fiddle with that
ZashSure, but I think you still wanna discourage people from sending raw strings too often.
pep.And I don,t really see the point in specifying it anyway
moparisthebestlast night I was purposefully trying to send ridiculous things to see how servers would handle them for instance, ended up just not using any library because none of them had good support for this, so "testing" would be at least one use-case
pep.moparisthebest, in any library it's possible to declare new tags to include as part of stanzas.. I am all for writing (better) documentation in libraries
ZashI know in verse you can access the underlying socket and do whatever, but it's easy to compose arbitrary xml without reaching for strings
ZashAnd prosody too
DanielNot just documentation. Also make it easier. The way slixmpp does it is horrible
DanielWhere as prosody stuff is relatively easy to understand
pep.Daniel, I don't disagree about slixmpp being horrible :)
DanielI mean for complex things prosody also gets in your way
Link MauveI usually found the declarative way in slixmpp (and in stanza.io and various other projects from Lance) to be quite good for extensibility.
DanielBut for a simple I want to add a key value pair it's super easy
pep.Link Mauve, fwiw I'm still confused when adding an ElementBase in slix
Link MauveReally? :/
pep."what attributes do I need again, and what do they do"
moparisthebesthttps://github.com/moparisthebest/jDnsProxy/blob/master/xmpp-dox/src/main/java/com/moparisthebest/dns/xmpp/DnsIq.java#L41 java/smack isn't much better here
DanielThe slack webhook thing is kinda nice
DanielI mean it's not exactly what we need. But it helps me understand the problem space better
Dele Olajidehas joined
ZashMUC bots needing to actually join the relevant rooms is a bit awkward, the slack thing doesn't have that problem. But it's awkward in another direction instead IIRC
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
adiaholichas left
adiaholichas joined
Yagizahas left
flow> larma> I just wonder how we are considering to add stream.send_json(to, json), when we don't have stream.send_xml(to, XML)
Probably because the data users want to send is already in json. And that does not mean that an API should (or can) not provide "sendXml(to, xml)"
Zashsend_whatever(to, mimetype, binary, data)
pep.What Zash say
pep.I personally don't want to include 42 parsers in my lib. Let the user validate themselves
pep.Even though.. I'm not fond of the mimetype thing
pep.I'd say s/mimetype/namespace/ :)
flow> moparisthebest> that is generally my complaint with about every XMPP library I've ever used, they all make you jump through a series of hoops when I just want to send a String
One of the first things Jive Software implemented in Smack ~20 years ago was an API to make that easy
flowpep., I don't think including a parser is a necessary prerequisite for such an API
flowZash, binary *and* data?
Zashflow: boolean for whether to base64 the data blob I guess
flowahh, is_binary (or so) then
pep.isn't udt^WJSONthing requiring the JSON data to be validated? (well it does say "JSON", that means valid JSON)
lorddavidiiihas left
Zash(mod_rest has a thing for udt already)
flowpep., if you are prepared to receive json, then you probalby have a json parser (and validator) already available,
moparisthebestvalidation sounds like the recipient's problem :P
flowI don't think I would bundle one with smack if I where to implement something like simple json
pep.moparisthebest, if you implement that you implement both sides
pep.I guess
moparisthebests/recipient/consumer of that json data/
pep.In any case, I don't think all of this is necessary anyway..
mukt2has left
lorddavidiiihas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
Yagizahas joined
eevvoorhas joined
mukt2has joined
adiaholichas left
adiaholichas joined
Dele (Mobile)has joined
adiaholichas left
adiaholichas joined
mukt2has left
mukt2has joined
adiaholichas left
adiaholichas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
pdurbinhas joined
adiaholichas left
lorddavidiiihas left
Dele Olajidehas left
Dele (Mobile)has left
Dele Olajidehas joined
lorddavidiiihas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
pdurbinhas left
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
pdurbinhas joined
Dele Olajidehas joined
Dele Olajidehas left
larmaflow, if you don't validate that the string provided by the user is in fact valid JSON, one could argue that you are not standards compliant, because the json XEP clearly clarifies that what is in a <json> element MUST be valid JSON according to (insert reference to RFC here)
flowlarma, I didn't say that nobody should validate it. Just that it don't see it as strictly necessary to include a json validator in smack if I where to add support for something like simple json
moparisthebestlarma, is it the library's job to ensure anything sent using it is standards compliant? that sounds... very wrong?
moparisthebesthow do you develop new extensions then, for example
larmamoparisthebest, not in general, but when it provides a highly abstract API, like the send_json(to, data) I would expect it to only send standards compliant things on the wire
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
larmaI also expect it to escape my strings when I do send(to, body) with body = "x < pi &&", no?
Dele Olajidehas left
flowsure, but if you already ensure in a higher level that 'data' is valid json, then it only adds an unnecessary validation step if the library performs another check if data is json
moparisthebestif the API lets me send a string I expect it to send exactly the bytes I tell it to
moparisthebestif the API lets me send some XML object, then I expect that XML lib to do that kind of escaping
flowI does not really hurt, but I don't see it a strict requirement for a library to perform that validation here
KevI suspect that's an unusual position. If would find it surprising if message->setBody(someString) required me to first escape somString.
moparisthebestyea ^ that sounds like the second thing, some XML object that should be escaping things
moparisthebestif all xmpp client libs refuse to send non-valid things, how are we testing that server implementations deal with bad input correctly? (or are we?)
pep.moparisthebest, I doubt allowing to send bad input is a good API
larmaDo you think it should be allowed to do send_json("test@example.com", "urn:example:type", "Nope, I don't do JSON here")? And on the recipient side it would just provide a string. So that if people don't want to do JSON they'll just end up using that method and we have an even worse problem as right now with JSON in body
pep.You can have escape hatches for sure in the lib
pep.But that shouldn't be the default
moparisthebestwell sure, completely agree there
KevAt least for Swiften the idea is that stuff you send should largely be valid, and that there's an escape hatch for shoving octets onto the wire (which will break everything).
Kevi.e. it makes it hard to do the Wrong Thing.
moparisthebestsounds right, no argument there
calvinhas joined
Marchas left
Marchas joined
nyco-2has left
nyco-2has joined
Dele Olajidehas left
Dele Olajidehas joined
lorddavidiiihas left
pdurbinhas left
lorddavidiiihas joined
Wojtekhas joined
mukt2has left
calvinhas left
calvinhas joined
mukt2has joined
adiaholichas joined
andrey.ghas left
mukt2has left
mukt2has joined
Nekithas left
Nekithas joined
Dele Olajidehas left
Dele Olajidehas joined
rionhas left
rionhas joined
davidhas left
andrey.ghas joined
davidhas joined
nyco-2has left
mukt2has left
mukt2has joined
Link Mauvemoparisthebest, I’d also expect a library implementing JSON to not take a raw string as input, but the language representation of the JSON thing (for instance a Python dict containing lists and other dicts and strings and such), so that the user of the library couldn’t do it wrong.
Link MauveOf course, the raw XML extension API wouldn’t do this validation, so you could send invalid JSON using it.
mukt2has left
Dele Olajidehas left
Dele Olajidehas joined
lovetoxhas joined
Dele Olajidehas left
mukt2has joined
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
mukt2has left
Douglas Terabytehas joined
Douglas Terabytehas left
Douglas Terabytehas joined
Dele Olajidehas left
Nekithas left
nyco-2has joined
pdurbinhas joined
Douglas Terabytehas left
adiaholichas left
adiaholichas joined
calvinhas left
calvinhas joined
pdurbinhas left
davidhas left
davidhas joined
Ellenor MalikRyanair just screwed everything.
Ellenor MalikDo I have to, like, hire Landor myself to come up with a new brand name for XMPP?
Link MauveSnikket it is.
Ellenor Malikexcept that's not XMPP. That's a subset of XMPP
Link MauveHow so?
Ellenor Malikone could argue it's even a "proprietary" messenger.
Link MauveGood luck, but how?
mukt2has joined
moparisthebestwhat? how could you argue that?
jonas’Ellenor Malik, that’s bullshit.
nyco-2has left
jonas’of course it’s a subset of XMPP. why would it need support for the IoT XEPs.
jonas’and it’s all free and libre software, there’s nothing proprietary about it.
jonas’MattJ explained it in more detail here: https://old.reddit.com/r/xmpp/comments/f0el07/can_someone_explain_to_me_whats_the_point_of/fgto5h0/
nyco-2has joined
jonas’you know about that thread, so I’m assuming you are intentionally ignoring data
Ellenor Malik> jonas’ has written:
> of course it’s a subset of XMPP. why would it need support for the IoT XEPs.
why do you need a whole-ass XEP for IoT anyway? the way you control IoT on IRC is just by a standard privmsg, and XMPP doesn't need to be any different
nyco-2has left
Dele Olajidehas joined
Link MauveEllenor Malik, err, no.
moparisthebestEllenor Malik, my take is for developers that know to search "xmpp" there are numerous servers/clients/etc, for "users" that just want "to chat", that's what snikket seems to be targeting, it's still standard/interoperable/federating/open xmpp
Link MauveEncoding machine-readable stuff in the body would be utterly stupid.
Ellenor Malikmoparisthebest: the whitelabel clone of conversations is refusing to connect to under-compliant XMPP servers. to me that seems far too close to a proprietary system for anyone to be comfortable with it
Link MauveEllenor Malik, you mean that your server didn’t implement XEP-0401 yet?
Link MauveThat’s a complaint to direct to your server implementation, not to that client.
Link MauveThat’s a complaint to direct to your server implementation, not to a client using it.
Danielit's also not true
Danieli’m fairly certain that snikket would open xmpp:anyserver.tld?register
Danielnot sure why you would want to use snikket with non snikket servers
Danielbut if you wanted to you could
mukt2has left
moparisthebestif you know about non-snikket servers then snikket probably isn't for you
Dele Olajidehas left
Dele Olajidehas joined
DanielThe amount of bullshit and conspiracy theories that go around when ever someone - who has a well established record for working in the xsf - tries something new, is unbelievable
DanielHappened to me with Quicksy as well
jonas’it’s almost as if people didn’t want XMPP to change to something successful
Ellenor Malikit's almost as if refusing to connect to slightly behind the curve servers amounts to vendor lockin
jonas’some call it vendor lock-in, others call "providing a decent UX in a federated system"
jonas’take it or leave it, noones forcing you
jonas’MattJ won’t make Snikket not federate.
jonas’I’m rather confident in that.
moparisthebestanecdotal quicksy story, was having an argument about why xmpp was superior to everything in an IRC channel recently, and they brought up how hard it was to install Conversations and know what a JID and a server etc was, get an account, compared to Signal where you just install it and it works
moparisthebestI said "what about Quicksy" and got "oh, hadn't seen that before, looks really nice"
moparisthebestanother one brought over to the dark side >:)
jonas’puts some cookies on the table
Ellenor Malikif you think I'm mentally ill now, try feeding me some cookies.
moparisthebestI'm not personally going to use Quicksy or Snikket, I already have a setup I like, but I am VERY happy to recommend them to others that do not
Ellenor Malik(don't)
Ellenor Malik> jonas’ has written:
> some call it vendor lock-in, others call "providing a decent UX in a federated system"
the alternative is to prompt. "The presence server you have chosen does not support all of the features of Snikket. At this stage, you have three choices. Continue connecting, and experience marginally degraded functionality (you'll still be able to chat and join conferences), pick another server (and then the client can call a few web servers in a round-robin which can recommend a few servers based on geography), or, if you know the server administrator personally, flame them and tell them to upgrade to Snikket."
> take it or leave it, noones forcing you
Welcome to juntist Brazil.
> MattJ won’t make Snikket not federate.
> I’m rather confident in that.
still, makes me uncomfortable
DanielEllenor Malik: can you post a screen shot of the error message where it says you can't use a certain server?
Ellenor Malik...
calvinhas left
calvinhas joined
Ellenor Maliki was providing an example of an error message I would supply if the server was not fully compliant.
DanielNo. You said earlier that snikket is doing vendor lock in. I'm asking you to provide proof for that
ZashI just got Snikket (client) to connect to my main account on my non-snikket server that doesn't even have registration.
Ellenor MalikZash: oookaaayy
ZashHad to `qrencode -t ansi 'xmpp:me@myserver.tld?register'` and uncheck a hidden checkbox tho
Ellenor Malikthat's more than a mite absurd
Ellenor MalikI'm pretty sure on the server side snikket refers to a feature set and not a specific server
moparisthebestyes "modern xmpp" for lack of a better term
ZashHuh
jonas’moparisthebest, better term .... liiiike .... snikket?
moparisthebestsure :)
Ellenor MalikZash: having to qrencode the registration seems more than a mite barrier to entry shaped
mukt2has joined
ZashNo, quite the opposite
Ellenor Malik(she says, while planning a Website for her XMPP server which will do just that)
ZashQR code with `xmpp:example.com?register` on your website would work just fine in Conversations too
moparisthebestEllenor Malik, have you ever instead tried to send someone a username and password over SMS or something
sonnyhas left
sonnyhas joined
Ellenor Malikthe main issue is getting people to transcribe domain names
moparisthebestalso the people that always capitalize the first letter of everything without telling you
Dele Olajidehas left
Ellenor Malikwhy are we sending passwords over SMS anyway?
Dele Olajidehas joined
moparisthebestI said or something :)
moparisthebestI've done it using Silence before
Ellenor Malik... but why are we sending qr codes over SMS?
calvinhas left
calvinhas joined
moparisthebestyou don't
Ellenor MalikI should probably come up with a module to an XMPP server that makes it so that users can only federate if they verify their phone number
moparisthebestwhat are you going to use to verify phone number?
Ellenor Malikthat is, they can only message out of the local server
jonas’Ellenor Malik, sounds like a plan for anti-spam in some deployments
eevvoorhas joined
moparisthebestEllenor Malik, also sounds like you are just talking about https://www.kontalk.net/
Ellenor Malikeverything that can be done by someone with a 132 iq has already been done
moparisthebestfyi that's mostly standard xmpp too and federates
moparisthebestlast I checked he was taking out the non-standard extensions slowly
Ellenor Malikprobably preparing to shut down
Ellenor Malikwhich is bad
Dele Olajidehas left
Dele Olajidehas joined
dwdhas joined
mukt2has left
j.rhas left
adiaholichas left
adiaholichas joined
Dele Olajidehas left
Wojtekhas left
Wojtekhas joined
mukt2has joined
SubPubhas joined
archas left
archas joined
archas left
archas joined
sonnyhas left
mukt2has left
calvinhas left
calvinhas joined
calvinhas left
calvinhas joined
j.rhas joined
archas left
archas joined
davidhas left
davidhas joined
LNJhas left
mukt2has joined
Douglas Terabytehas joined
rionhas left
rionhas joined
pdurbinhas joined
Douglas Terabytehas left
pdurbinhas left
davidhas left
mukt2has left
mukt2has joined
krauqhas left
SubPubhas left
davidhas joined
Yagizahas left
krauqhas joined
mukt2has left
mukt2has joined
MattJI'm happy that most people in the community do understand the motivation behind Snikket <3
MattJand yes, you can connect to non-Snikket servers with the Snikket app, and yes, you can connect to a Snikket server from a non-Snikket app
Marchas left
Marchas joined
MattJBut it's not advertised that way because that's not really what provides the best user experience
MattJand I have had to explain to multiple people who try to use Snikket with non-Snikket servers that they really really should just go and use Conversations
moparisthebestyou'd have to explain "what is XMPP" to people that *just* want a chat app
MattJThe problem is that anyone in this room, or who even knows what XMPP is most likely is not the target audience for Snikket
moparisthebest*eyes glaze over* thinks to self: when will this idiot shut up so I can just go install Signal
MattJOff to dinner now, don't worry :)
moparisthebesthaha sorry if the sarcasm wasn't implied, that's an impression of a user who just wants a chat app when you go into a "what is XMPP and why is it the best" explanation
adiaholichas left
Douglas Terabytehas joined
MattJ:)
!XSF_MartinDon't explain it, just force them to use it. 😃
calvinhas left
debaclehas joined
Shellhas joined
mukt2has left
mukt2has joined
krauqhas left
Ellenor MalikMattJ: would it not be ideal to splash up a warning when a non-snikket compliant server is used?
jonas’I’m halfway through writing down the (xmpp) protocol used by search.jabber.network in a proper ProtoXEP by the way.
jonas’or rather, a cleaned up variant of that.
Marchas left
moparisthebestnice
Marchas joined
davidhas left
calvinhas joined
kuvohhas joined
kuvohhas left
pep.for s.j.n, I'd like not to have to use HTTP btw, and some clients seemed to prefer that for possible anonymity purposes. jonas’ would it be a problem for you if servers provided anon hosts that have s.j.n whitelisted? (so potentially you could get spammed from all around)
jonas’pep., interesting idea
jonas’I mean, I can get spammed via HTTP already
pep.Right
jonas’and with tor you can make that even more fun
jonas’I don’t block anything at the moment
jonas’but we’ll have to write down how to behave when I reply with rate-limiting error codes
kuvohhas joined
jonas’also, see what I wrote in https://github.com/horazont/muchopper/issues/51
kuvohhas left
mukt2has left
moparisthebest<body>{"code":"502", "message":"please come back later"}</body>
jonas’stomps moparisthebest
jonas’to make this less painful: <error type='wait'><resource-constraint xmlns='...'/><rate-limit xmlns='urn:xmpp:channel-search:0'/></error>
mukt2has joined
jonas’moparisthebest, there’s SO MUCH wrong with that. I can only compliment you, you put a lot of triggers in just 63 bytes.
jonas’only thing that’s missing is some unicode shenangians
Alex_has joined
Alex_has left
Alex__has joined
davidhas joined
moparisthebestjonas’, lol yea "how to trigger XMPP developers in only 63 characters!!!"
moparisthebestalso HTTP developers if they are paying attention
lskdjfhas left
lskdjfhas joined
moparisthebestI guess I could have used smart quotes instead...
jonas’oarrr
calvinhas left
MattJ😁
moparisthebestjonas’, just for you <body>{“code”: “502”, “message”: “please come back later”}</body>
ZashWhat have you cursed us with‽
Maxhas left
mukt2has left
Maxhas joined
calvinhas joined
calvinhas left
calvinhas joined
marchas left
mukt2has joined
marchas joined
Marchas left
pdurbinhas joined
Shellhas left
Shellhas joined
archas left
archas joined
Shellhas left
pdurbinhas left
Shellhas joined
Tobiashas left
lovetoxhas left
mukt2has left
lorddavidiiihas left
Shellhas left
Shellhas joined
mathijshas left
calvinhas left
mukt2has joined
karoshihas left
karoshihas joined
Wojtekhas left
LNJhas left
eevvoorhas left
LNJhas joined
archas left
archas joined
mukt2has left
gavhas left
gavhas joined
pep.I have moved the Summit minutes (pad) to the wiki, https://wiki.xmpp.org/web/Conferences/Summit_24#Minutes
pep.I wanted to do something a bit more elaborated, but I don't have much time so that'll do. There is still quite a few pieces missing, I'd appreciate if people present could have a look