Ge0rGAm I the only one to be baffled by the Yes-Yes-Yes-No-Yes order of questions in the Last Call emails, every single time?
archas left
Guushas left
Guushas joined
Valerianhas joined
vurpohas left
vurpohas joined
ralphmhas left
nicolas.veritehas joined
Tobiashas joined
Guushas left
nicolas.veritehas left
Guushas joined
Tobiasyes you are
Ge0rGTobias: how can you know? :D
efrithas joined
nycohas joined
Tobiasaww...multi-client support in major IM apps, "WhatsApp is open on another computer or browser. Click “Use Here” to use WhatsApp in this window."
nicolas.veritehas joined
Ge0rGTobias: And you have also stored XSS vulnerabilities in WhatsAppWeb✎
Ge0rGTobias: And you have also stored-XSS vulnerabilities in WhatsAppWeb ✏
Tobiaswhat web app doesn'T have XSS vulnerabilities, that's their feature, isn't it?
vurpohas left
Guushas left
Guushas joined
Ge0rGLast time I audited a web app, I was able to type HTML/JavaScript right into the "Send message to admin" input box. Instant root!
vurpohas joined
moparisthebesthas left
moparisthebesthas joined
Guushas left
Guushas joined
intosihas joined
efrithas joined
efrithas joined
rionhas joined
rionhas left
ralphmhas left
suzyohas joined
nycohas joined
Tobiasjonasw, am I missing something or does xmpp.org already show the data based on your JSON system?
jonaswno, I think it does
Valerianhas left
jonaswhttps://github.com/xsf/xmpp.org/pull/278 cc @ Ge0rG (who wants to write the announcement mail for software developers)
A bit of manual cannot hurt for the renewal thing.
Tobiasjonasw, nice..and expiration also works as soon as last_renewed is set
jonaswthere is also that deadline hardcoded in pelicanconf.py, we should adapt this once the mail is sent out
jonaswafter that deadline anything without renewal disappears magically
Tobiasso yeah...an annoucement mail would be nice to tell people to create PRs that set the last_renewed value for their project to a value in the past and that after a months or so, all entries without a last_renewed set will be removed
jonaswwe can set this to date_of_mail + 1 month when the mail is sent out.
jonaswno need to modify the last renewal of projects for us.
jonaswah, nevermind, I misunderstood you. disregard the last one, it was unrelated.
nicolas.veritehas left
jonasw(true, but unrelated)
archas joined
Tobiasjonasw, could the config also be relative? like today - 13 months or so
jonaswnot sure what you mean
Ge0rGhttps://op-co.de/tmp/deprecation-mail.txt draft email with PR link
jonaswthere are two reasons to kick an entry from the list in the code (aside from date parsing issues):
1. if they have no renewal timestamp set, they are kicked after the date in STRICT_RENEWAL_DEADLINE has passed
2. if they *have* a renewal timestamp set, they are kicked if it is more than ENTRY_LIFETIME in the past (currently set to 365 days)
Tobiasjonasw, ahh..so it does more than I thought :) good
Ge0rGjonasw: ENTRY_LIFETIME should be ~13 months to provide for a grace period
jonaswit does everything that was asked I think :-)
jonaswGe0rG: fine with me. make a PR ;-)
Tobiasright...I thought we'd just delete projects with no date set after the deadline, but your STRICT_RENEWAL_DEADLINE config already does this :)
Tobiashas joined
Tobiasdoes this = has the same effect
Ge0rGjonasw: -ETOOMANYPENDINGPRS
jonaswGe0rG: your email footnotes have two times [2] in them
Ge0rGjonasw: damn off-by-ones. Fixed.
jonaswGe0rG: it might be better to link to the commit rather than to the PR
jonaswthe PR does a lot of unrelated stuff
jonaswit might be even better to link to the README
jonasw(and we can update the readme with a link to the example commit once the branch is merged)
Ge0rGjonasw: but I did link to the commit. It was just relative to the PR and not in the xsf repo.
jonaswargh
jonaswI cannot read urls
jonaswsorry
Tobiasjonasw, right...maybe we should add a section to https://xmpp.org/software/ how authors can add new software and update the date
Ge0rGjonasw: URLTLDR
jonaswTobias: might be wise, yes
Ge0rGTobias: maybe we should add it to some README and link it from https://xmpp.org/software/
Tobiaswhy not have the readme at https://xmpp.org/software/ ?
jonaswhttps://github.com/xsf/xmpp.org/pull/278/commits/73cd247e4af6624e60ac29bf33c3f4bf46677786#diff-ac579daf3602a0a4ea57b5fdd7f73dd8 like this readme?
jonaswTobias: because it’s long and technical. If we want normal users to use the software directory there, we shouldn’t have that information on it
Tobiasyeah..that what you linked to looks qutie long..linking to it sounds sensible
jonaswI thought I’d rather make it too detailed than too shallow.
Ge0rGYay. I've been reading 0369 for the last two hours, and I only managed to get to 6.1.6
jonaswGe0rG: you are in luck! it appears that prefer hidden is going to be broken out of that XEP. so less to read next time ;-)
jonasw(which I think is a good idea, I also thought that might make sense to break out into an add-on)
Ge0rGjonasw: yeah, I actually had three remarked about prefer-hidden that I already deleted.
jonasw:)
TobiasGe0rG, you should order the audiobook version read by helen mirren
jonaswthanks for going through it :)
jonaswthere is one? :-O Tobias
Tobiasthere should be one
Ge0rGTobias: but I want the one read by Morgan Freeman('s German lipsync voice).
Tobiashttps://youtu.be/zmeF2rzsZSU?t=2m19s :)
TobiasGe0rG, you mean Nelson Mandela?
Guushas left
vurpohas left
vurpohas joined
Guushas joined
Valerianhas joined
Tobiasjonasw, but yeah..nice work you did there...thanks :)
jonaswno problem :-)
jonaswyou’re welcome
jonasw(I need to get used to using "you’re welcome" in en locales)
Tobiasde nada
vurpohas left
vurpohas joined
nicolas.veritehas joined
nicolas.veritehas left
Guushas left
Guushas joined
vurpohas left
vurpohas joined
nycohas joined
Zashhas joined
pep.has joined
Yagizahas joined
jubalhhas joined
Ge0rGresolved my XMPP action items for today.
Ge0rGWhen is the next council meeting due?
TobiasGe0rG, they usually happen on a weekly basis
goffihas joined
Ge0rGSo "yesterday"
nycohas joined
TobiasGe0rG, which reminds me to write up minutes for yesterdays meeting...nothing is more exciting than yesterday news
Ge0rGTobias: was there an exciting discussion of #436?
BunnehTobias: XEP-0045: Add <x/> tag to MUC-PMs #436
https://github.com/xsf/xeps/pull/436
Tobiasi don't remember discussions about that
Ge0rGhas joined
Ge0rGIt looks like my train is arriving. I'm looking forward to read minutes.
Tobiashttp://logs.xmpp.org/council/2017-03-15/
Tobiasshoo shooo
vurpohas left
vurpohas joined
jonaswhuh
jonaswis there any update on my protoxep?
jonasw(I’m not familiar with the process, so please don’t mind me asking.)
jonaswah
jonaswI am too stupid to search
Tobiasjonasw, it's awaiting votes...council members have two weeks to vote
sonnyhas joined
jonaswah, I see
jonaswdidn’t know that "two weeks" detail
HolgerGe0rG: It was mentioned last week http://logs.xmpp.org/council/2017-03-08/#16:32:52 (and then on the list) but maybe you mean a follow-up discussion?
Ge0rGHolger: yes. I've done what was asked from me and hoped it would get discussed again
HolgerAh ok.
Ge0rGLooks like adding things to the PR wasn't enough. Need to bother someone to add it to trello.
sonnyhas joined
TobiasGe0rG, yup..what's not in trello isn't discussed :)
jonaswmail to council@?
Ge0rGTobias: can you add it please?
Tobiassure
TobiasGe0rG, seems there are pending votes on https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg
Tobiasone of which is mine...will review that now then :)
Ge0rGTobias: it might need a revote (is that a thing), because I changed the PR based on council feedback
sonnyhas joined
TobiasGe0rG, i'll put it on the agenda to discuss this next meeting
Steve Killehas left
Steve Killehas left
Ge0rGTobias: thanks very much! Is there anything I can do to accelerate the process, so that there is no more 1-week latency in the feedback loop?
Ge0rGOr even 2-week in this case
Steve Killehas joined
TobiasGe0rG, get dwd to vote on it
jonaswGe0rG: have you sent the deprecation announce already?
Ge0rGjonasw: to board? Yes.
jonaswwith the link to the commit?
Ge0rGjonasw: yes
jonaswhm, then I’ll make sure that the commit ID doesn’t change :)
Tobiasseems i already voted on Ge0rG's PR, just forgot to mark it in Trello...now reviewing caps2
jerehas joined
jonaswhas left
Ge0rGjonasw: it has a todo note
sonnyhas joined
mhterreshas joined
suzyohas left
suzyohas joined
nicolas.veritehas joined
nicolas.veritehas left
jonaswGe0rG: what has?
Martinhas joined
Ge0rGjonasw: the URL
jonaswah okay
nicolas.veritehas joined
HolgerTobias, dwd:
> <Tobias> Dave Cridland, well..p1 implemented it [MIX] too, not?
> <Dave Cridland> Tobias, They implementing grouchat over pubsub; not quite the same thing.
They implemented both.
Holger(Well, an early revision of MIX.)
nicolas.veritehas left
dwdHolger, That's actually the one I was referring to. The thing they said was early MIX was a brief discussion; it didn't, for example, handle <presence/> or <message/> stanzas in the traditional way, a design feature that lasted all of a week or so and was contentious at the time.
vurpohas left
nyconycohas joined
HolgerYeah whatever, just wanted to clarify that there's two totally unrelated pieces of code, so you were both right :-)
vurpohas joined
nicolas.veritehas joined
nicolas.veritehas left
HolgerOh.
nicolas.veritehas joined
nicolas.veritehas left
HolgerSorry you were referring to mod_mix, finally got that now.
HolgerWhile at it, personally I think if there's any chance to move non-essential functionality out of the core MIX spec into separate XEPs, that should be strongly considered.
dwdHolger, I agree. I'm not sure what remains to be removed.
nyconycohas left
HolgerI can totally see use cases for anonymous chat, but they don't seem to be the common me, so it would be nice if implenting that would be optional (esp. on the client side_.
Holger*implementing
TobiasHolger, indeed...it's quite an amount to review
MattJTo be honest I'm not sure that MIX should even attempt to compete with use-cases that MUC already covers
MattJbut maybe it's too early in the morning to be so controversial
jonaswwhich use-cases does MUC actually cover?
dwdHolger, Anonymity seems very fundamental to operations, though.
dwdHolger, And crucial where it arises.
dwdjonasw, Being shit on mobile?
dwdNo, seriously, MUC covers >90% of what anyone needs for pure synchronous ephemeral chat. I don't think it's hard to make MIX cover that, too, but I think MIX can and should spread its wings wider, at least in potential.
MattJdwd, because?
MattJ(to your comment about mobile)
Steve Killedwd: +1
dwdMattJ, The tie between your session and your participation, WRT mobile. It can be worked around to some degree, though, but it's a bit of a pain.
MattJRight
MattJMaybe it is a bit of a pain, but here comes a whole new spec that isn't exactly trivial either
dwdMattJ, I suspect that most servers will find it *easier* to implement than we have done do far in Openfire.
dwdMattJ, Due to the architecture, we couldn't reuse any of the MAM code, nor PubSub code, nor even the MUC code.
dwdNot that any of that code is bad, it's just either in the wrong place, or highly focussed to what it does.
Tobiaslike the s2s code? :)
dwdTobias, The S2S code is just very old, basically. We've updated it a considerable amount over the past few years, including fixing a bunch of security issues.
Manchohas left
Tobiasstill can't recursively disco igniterealtime.org
dwdTobias, The MUC code, and the pubsub code, both have near-complete, all-options, implementations of '45 and '60 respectively, with full clustering.
Manchohas left
dwdTobias, Sure - I've not fixed the issue you found yet. It's a hang-up of Openfire originally assuming that x.domain.example could always be reached at domain.example; that assumption has entered code in a large number of cases.
Guusno-one is arguing that that s2s bug should be fixed, Tobias. Daytime jobs and all.. :)
TobiasGuus, dwd, yeah i know..just nitpicking :)
Guusinterop problems are annoying
Guusyou should simply switch to Openfire and be done. :)
Guusducks, runs
TobiasGuus, and you are 100% sure that openfire would not have that issue :P
Guus(I'm somewhat in a defiant optimistic mood now that it turns out i'm not living in the newest populist-governed country)
dwdTobias, Actually yes, because the assumption operates bidirectionally.
dwdGuus, As you should be.
Tobiasdwd, i wonder if there could be a security issue there
dwdTobias, Actually, I suspect this case is due to authenticating domains individually rather than authorizing as domain-pairs. So no security issue.
Tobiasdwd, didn't you propose some standard for that once? bidi or dwd?
GuusTobias: yes.
Guusalso, what he said
Guus(eww, lag)
dwdTobias, No. Those still operate on pairs.
Tobiasbut it was a practice gtalk was doing right? reusing a s2s connection for all their domains?
dwdTobias, That's different... Piggybacking is fine. But you still have to authorize pair-wise.
Tobiasok
Valerianhas left
nycohey, are you aware?
https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-the-best-ways-to-achieve-them.html
sorry, looks like a shameful ad...
Flowhas joined
nycoit is interesting, as we discussed that many many times
nycohow to read the massive amounts of XEPs
nycohow to triage the massive amounts of infos that are behind each XEP
archas left
archas joined
nycodo it give ideas on how to present our XEP list or feature list?
sonnyhas left
Manchohas left
Ge0rGWow, a burst of discussion. I think that the fact it takes multiple hours to read and understand MIX might indeed mean we won't see IM MIXes any time soon.
Ge0rGWhile MUC is really broken in some regards, it can be fixed with a bunch of undocumented hacks.
jubalhhas joined
kalkinhas joined
jonaswhas left
Valerianhas joined
kalkinhas left
Tobiasit's all a matter of having the right abstraction in your software...and if you then already have pubsub and MAM in place, i don't think MIX is that mich work, at least a minimal version
Ge0rGTobias: I've tried to read the XEP (admittedly I also did some light editing along the way), and I managed to read ~40% in 2 hours.
Ge0rGTobias: if you have the right abstractions in your software, it still takes multiple hours to understand how to stack them
Tobiassure
Ge0rGI'm not sure if it would help to refactor the XEP into "Client Developers Read This", and the same for Server Devs and Service Devs.
Tobiasmostly it covers so many things...i mean user experiences like whatsapp group chats, doesn't require 4 different affilations/roles, etc.
danielhas left
Ge0rGTobias: yes, it attempts to be everything to everyone.
danielhas joined
Ge0rGIf history is repeating itself, we'll have a MIX-Light in five years that is a one-man-show slim rework of MIX, similar to what MAM is to Message Archiving, PEP is to PubSub and Blocking Command is to Privacy Lists.
Ge0rG...and http-upload is to Jingle FT
Ge0rGTobias: btw, you intended to update https://wiki.xmpp.org/web/XEP_and_RFC_Remarks/RFC_6121:_XMPP-IM with that one corner case you were talking about yesterday
Tobiassomewhere I have a tab open about that, yes
Tobiasopens a new tab for it :)
Flowhas left
Guusthat makes three rows of tabs, right?
Tobiaschrome can't do mulit rows
Tobiasbut there's a nice plugin that removes duplicate tabs :)
Valerianhas left
Valerianhas joined
vurpohas left
vurpohas joined
kalkinhas joined
sonnyhas joined
Archas joined
ArcAmazon Smile is donating 10% of purchases to your chosen charity today
Arcso if you've selected XMPP as your charity on smile.amazon.com be sure to make purchases ;-)
mathieuiif you’re in the US
Ge0rGArc: XMPP is a charity?
TobiasGe0rG, sure...feeding the hungry in africa
kaboomhas joined
sonnyhas left
sonnyhas joined
Ge0rGXenophobics' Money for Poor People?
Ge0rGI'm sure it's a SCAM.
TobiasGe0rG, they probably delegated the chairity part to paypal..they are experts at this
intosiSuper Cool Automatic Messenger?
jubalhhas left
Viniloxhas left
nicolas.veritehas joined
nicolas.veritehas left
dwdI should put MIX onto dave.cridland.net, shouldn't I? Are any [other] client developers wanting to play?
jonaswdwd: yes
jonaswnot this month, but yes
dwdjonasw, What library?
jonaswaioxmpp
Valerianhas left
dwdjonasw, Ah, heh. We nearly put MIX support into that, before deciding to base our test suite around Java instead.
jonaswaw pity
dwdjonasw, We have partial implementation, so far, only in stanza.io. I'm awaiting confirmation that'll all be offered upstream (I can't imagine why not).
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
archas left
archas joined
Tobiashas joined
nycohas joined
Manchohas joined
Valerianhas joined
Valerianhas left
nycohas joined
jerehas joined
nicolas.veritehas joined
Ge0rGdwd: any chance you can have a look at https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg and maybe provide feedback if action is required from my side, regarding repairing the MUC protocol?
TobiasGe0rG, btw: just added the text to the wiki page
Ge0rGTobias: thanks. Any ideas on how to fix that? Let server push a presence change to the other clients?
Tobiaswith full to and from attributes, yeah
dwdGe0rG, FWIW, I'm a little uncomfortable with "SHOULD" here, given you're adding a normative requirement post-facto. But I suppose this is probably as good as it gets, so I'm not going to block.
Yagizahas joined
Ge0rGTobias: I also noticed some multi client weirdness when *accepting* a subscription request, have you looked into that as well?
TobiasGe0rG, with accepting clients should receive a roster push, not?
TobiasGe0rG, also...i thought you were planning to replace the SHOULD with a MAY?
Tobias"TLDR either change the wording to MAY or add a sentence that implementations MUST NOT rely on it." <--- regarding that
Ge0rGdwd: thanks for the feedback. I think that we should be able to change our specifications over time, or we will end up with multiple generations of imperfect XEPs attempting to solve the same problem, evolving over the years
kaboomhas left
Ge0rGTobias: I added the sentence
dwdGe0rG, I don't disagree. I don't think that ought to involve simply declaring everything non-conformant. I don't see much of an option in this case, but that doesn't mean I'm happy with it.
Ge0rGdwd: IMHO, this approach has two benefits. First, it provides a clear path for new implementors to do the right thing. Second, it provides a bit of leverage to get existing implementations fixed.
dwdGe0rG, But they weren't broken...
dwdGe0rG, Not from a standards point of view.
dwdGe0rG, The actual protocol seems fine. My concern is with establishing the case that conformance isn't acheivable, or important.
Ge0rGdwd: they were compliant to an imperfect specification. One *could* consider this as broken
dwdGe0rG, Nothing is perfect. What we want is interoperable.
dwdGe0rG, And if things aren't interoperable, I'd rather they weren't despite following the specification rather than because they didn't.
dwdGe0rG, To put it another way, the pattern of declaring existing conformant implementations non-conformant isn't a pattern I'd like to see continue.
Ge0rGdwd: the two largest server implementations already exhibit the new behavior.
dwdGe0rG, That's irrelevant.
dwdGe0rG, I'm not saying the protocol change is bad - I've explicitly said it seems the right solution.
dwdGe0rG, I'm saying the choice of how the change has been made is not something I want to see ever again.
jerehas joined
vurpohas left
vurpohas joined
Valerianhas joined
intosihas left
nicolas.veritehas left
Ge0rGdwd: I don't see a better way to change MUC, except for a hard fork. And I think we all agree that that would not really be better.
waqashas joined
Ge0rGTBH, I'd like to also add more explicit words to 0045 regarding repeated join presences from the same full JID, and also do another take on the message ID stability for reflected messages.
dwdGe0rG, I agree this is the best of a bad bunch. I'm just saying that introducing new normative requirements to an existing specification is a problem.
dwdGe0rG, For repeated joins: I think there's consensus on the approach now, but it's not clear that we could put this in as anything more than an implementation note nonetheless. But Openfire, M-Link, and possibly others do it the "right" way.
dwdGe0rG, For message id stability, there's really no chance. I've changed my mind on that one over the years, but there's no universally-agreed "right" way. It is, however, "fixed" in MIX.
dwdGe0rG, Mind you, a note saying that implementations differ on message id stability would be good if you want to pen one.
Ge0rGdwd: my reading of rfc 2119 is more flexible, and I tend to accept "this was not part of the XEP when I implemented it" as a valid exception to a SHOULD.
dwdGe0rG, But that would suggest nobody would ever need to implement it... Which I don't think you really mean.
jonaswdwd: to be frank, as a relative newcomer to XMPP, this kind of stance is annoying. If there is a consensus on how something should be done, that should be written in the XEPs. Yes, during the transition period, some implementations won’t get it right. If that’s any better, we can make it a MAY first and after a year or so make it a SHOULD. But if you only make it an implementation note, I as a developer *cannot* at all rely on that behaviour, and it doesn’t look as if I ever can, so it is often useless to me.
Ge0rGdwd: MAY is completely optional. SHOULD at least provides direction in how to do it best
MattJAs far as I'm aware there was only ever one implementation that rewrote ids on messages, and it tripped up everyone when it appeared
dwdjonasw, I get that. The protocol can and should change. And if the specification says "SHOULD", you really should be able to rely on it. If we abuse that by introducing *new* normative languages into *existing* protocol, you can't.
jonaswdwd, Ge0rG: at the same time, when such changes are made, it is important to keep a hint on that this was changed "recently" inside the text. The list of versions below is not really discoverable, and finding important changes among the long list of changes is often hard (if the list of changes is even complete). Otherwise, one might be confused by implementation which do not handle this correctly; although that can be mitigated by making that (nothing) -> MAY -> SHOULD transition.
jonaswdwd: what about that MAY -> SHOULD transition?
sonnyhas left
jonaswnew implementations will see where the journey is going and there is something to point existing implementations to to achieve change
jonaswMattJ: I think daniel mentioned some gateways (Slack?) which did that, too
nicolas.veritehas joined
nicolas.veritehas left
dwdjonasw, I don't think introducing new normative requirements to existing protocol is *ever* the ideal path. I think we want to add new *protocol*, and then add this to the requirements for a given compliance level.
Kevjonasw: Spec versions (by protocol) should be interoperable.
KevIf I see feature X offered, I should know that I will interoperate with it if I implement the spec.
KevNot that I might or might not interoperate with it based on the age of the implementation.
jonaswokay, can we add a <feature/> then?
dwdOr that I might not interoperate with it next week.
jonaswthat would work for "I am not rewriting message IDs" for example
KevWhere we want to break things such that that isn't true, we do it by changing the negotiated feature (by our faux-versioning scheme).
dwdjonasw, Sure, and we can certainly do that.
KevThe issue here is that we're trying to avoid bumping the namespace version in MUC for obvious reasons.
dwdKev, We can also add new features.
Kevdwd: Different issue if you're adding a new feature, in a sense :)
KevBut yes.
dwdKev, MAM's recent :1 -> :2 transition could have done that, and it's somewhat frustrating that it hasn't.
dwdKev, But behavioural differences can be expressed as a new feature almost always.
Kevdwd: If thre's a better way, you could suggest rolling back to :1 with additional features.
devnullhas left
KevGiven I doubt anyone implements :2 (and if it's true that it just needs new features, that might be smart).
MattJProsody implements :2
Ge0rGMaybe we should entirely abandon the version bumping thing for new features and only use it for breaking changes.
MattJand iirc Conversations (but not 100% sure)
KevOh. 0.10 or something?
KevOr are we on 0.11 now?
MattJ0.10
jonaswGe0rG: +1
nicolas.veritehas joined
dwdMattJ, The MAM protocol itself is entirely unchanged on the wire. When used with MIX, nothing changes at all. Aside from everything, due to bumping the namespace/
nicolas.veritehas left
dwdGe0rG, Well, of course. That was *always* the intent.
dwdGe0rG, See XEP-0053, §4, point 2.
KevYes, new features that don't break the existing stuff should be by additional feature negotiation, not by bumping the namespace.
Ge0rGdwd: so it would be perfectly OK with you if I added the stable ID thing into MUC with an additional feature?
dwdGe0rG, You can't. :-) Otherwise I would have suggested it.
Ge0rGdwd: what's wrong with it?
dwdGe0rG, But you've done this by - quite rightly - allowing either clients or servers to add the PM marker.
dwdGe0rG, You could have a feature that indicated the server would do this for you. Perhaps you should.
Ge0rGdwd: I'm not talking about <x>, I'm talking about keeping the message ID on reflection
KevThe thing you can't do is say that servers SHOULD or MUST implement such a new feature. The point of upgrades-through-features is that they might not happen :)
dwdGe0rG, Oh that. Yes, sure.
KevNo reason a server can't advertise a feature saying "I'll keep ids stable".
archas left
archas joined
Ge0rGdwd: though I could imagine adding a <feature> for <x> as well, I'm just not sure what that would give in that specific case.
KevWhat you can't then do is say servers SHOULD or MUST implement this.
vurpohas left
vurpohas joined
Ge0rGKev: as I wrote earlier, I consider "SHOULD" to be the appropriate wording for such things, because it indicates the purpose and intent of our Great Master Plan. Foregoing that for the sake of backwards compatibility to the year 2002 is just not right
Ge0rGKev: It's the right thing to RECOMMEND server implementations to do these awesome new things nobody thought of in 2002, and to have a <feature> advertising that.
Ge0rGKev: actually, those two are almost completely orthogonal aspects of a protocol change.
Ge0rG(at least in my eyes)
KevI know you consider that. I just don't think that's the appropriate reading of SHOULD.
dwdGe0rG, And I strongly believe you to be wrong. Not because recommending people implement something new is wrong, but because RECOMMENDing people do something new is wrong.
Kev^
Ge0rGRFC 2119 does not provide approrpiate wording to go with the time.
dwdGe0rG, You can strongly encourage. You can advise. But if you RECOMMEND, you are changing the past.
KevI think Dave's spot on here.
Ge0rGdwd: I see what you mean.
dwdGe0rG, You *can*, though, say that for XMPP Server 2018 conformance, your new thing is REQUIRED.
Ge0rG"Server implementations created in the year 2017 or later SHOULD add an <x> tag to PMs. All other implementations are strongly encouraged to do so."
KevGe0rG: Which isn't needed for interop. So just go with 'strongly recommended' and MAY :)
dwdGe0rG, Sorta. We have XEPs specifically designed to do what you want. I RECOMMEND you help work on those. ;-)
KevIt doesn't matter whether it's a new implementation that doesn't do it or an old one, an entity has to cope regardless.
KevSorry, 'strongly suggested', senior moment.
Ge0rGI'm still not really convinced though. IMO our main goal is to have clear normative language that corresponds to the state of affairs as it is now, if only to attract new people to XMPP and to make implementors' lives as easy as possible. I'm okay with changing the past to achieve that, and people who feel betrayed by that can still dig up the old version of the XEP as their motivation to violate the new RECOMMENDation.
bjchas left
bjchas joined
nicolas.veritehas joined
nicolas.veritehas left
KevIf you implement the current version of a spec, and get weird interop problems with something else that looks like it's the same version, you've had your life made difficult, not easier.
Ge0rGreally, sentences like this are frightening in a network protocol specification:
"The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules."
suzyohas left
KevTerrifying. I can scarcely sleep at night.
intosihas joined
Ge0rGKev: everybody has their own nightmares, I suppose.
Ge0rGKev: re "get weird interop problems with something else", my reading of SHOULD in 2119 is that no other party may actually rely on it anyway, because you might always have a reason not to follow the RECOMMENDation
MattJI read it the other way: if you break a SHOULD, you have to deal with potential interop problems from that
KevWhat MattJ says.
KevOtherwise SHOULD is no different to MAY.
Ge0rGSo there is nothing in between SHOULD and MAY that conveys "do it this way, but if you don't then the others have to cope with it"
moparisthebestisn't MUST the word where breaking it makes interop problems happen?
Ge0rGI suppose this actually was a wise design decision on behalf of the Elders of the Internet
Kevmoparisthebest: No, SHOULD is.
KevGe0rG: If others have to cope with it, it's MAY.
moparisthebestthen how do MUST and SHOULD differ Kev ?
KevFrom an interoperability point of view - which is what 2119 language cares about
Kevmoparisthebest: For SHOULD, you might understand how one can not implement it without affecting interop.
Ge0rGKev: yes, on re-reading 2119 this became apparent to me now. Thanks to you and Dave and Matt for being patient with me
KevBut generally, in a spec a SHOULD should be matched with 'except when...'
Ge0rGSo effectively I MUST NOT change the normative language of an XEP without either making it conditional on a new feature or bumping the namespace.
vurpohas left
vurpohas joined
KevSHOULD NOT, except where you can mitigate interop considerations in some manner, yes.
Kev:)
Ge0rGKev: heh :P
moparisthebestyea I need to re-read 2119 it's been too long, thanks :)
Ge0rGHowever, the question remains what is the most elegant way to convey a new intent (like in the case of <x/>) and to make it a SHOULD eventually
Valerianhas left
Guushas left
Yagizahas left
Valerianhas joined
vurpohas left
vurpohas joined
goffihas left
waqashas left
suzyohas joined
kaboomhas left
Guushas left
uchas left
SamWhitedralphm: Ping, reminder to create me a trello board and add me to the XSF organization if possible
Tobiasand check if the board board and the council board belong to the XSF org
SamWhitedthe board board does, the council board doesn't; we should probably fix that.
Tobiasright
Ge0rGboard the board board?
Valerianhas left
Valerianhas joined
Valerianhas left
nicolas.veritehas joined
nicolas.veritehas left
KevI can fix the Council Board once Ralph makes me as XSF admin.
uchas joined
nicolas.veritehas joined
nicolas.veritehas left
Guushas left
jerehas joined
ralphmhas left
nicolas.veritehas joined
nicolas.veritehas left
ralphmhas joined
Yagizahas left
nicolas.veritehas joined
nicolas.veritehas left
waqashas joined
Ge0rGhas left
Tobiashas joined
kaboomhas left
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
Ge0rGhas left
Flowhas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
suzyohas left
suzyohas joined
Ge0rGhas left
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
nicolas.veritehas joined
nicolas.veritehas left
vurpohas left
vurpohas joined
waqashas left
Ge0rGhas left
bjchas left
suzyohas left
bjchas joined
suzyohas joined
Ge0rGhas left
Yagizahas joined
jonaswhas left
Manchohas left
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
Valerianhas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
Archas left
Yagizahas left
Yagizahas joined
Ge0rGhas left
ralphmKev: looking right now
Tobiashas left
ralphmKev: do you already have an Trello identifier?
ralphmSamWhited: you, too?
SamWhitedralphm: yup, it's just my name, same as my nick
SamWhitedI think I'm already on the board trello, but not in the organization so it shows up in my "Personal boards"
ralphmand now?
SamWhitedyup, that did it
SamWhitedExcellent; I can create an editor board now too. Thanks.
Tobiashas left
ralphmSamWhited: who owns the Council board, and can he/she initiate a transfer or something?
SamWhitedralphm: Let me check; I think it's Kev.
SamWhitedKev, Lance, and Tobias are admins; not sure if that's the same as owner or not.
Ge0rGhas left
nicolas.veritehas joined
nicolas.veritehas left
ralphmThere should be a 'change team' in the setting of the board
ralphmHmm. I'm not the owner of the Board board. Only bear and Laura.
ralphmeh, admin
Yagizahas left
ralphmEven though I am admin of the team, I cannot change that
SamWhitedBoard board appears to already be on the team, I think?
dwdI've nudged Laura, but she seems to be busy.
SamWhitedoh, you just want to be an admin; nevermind, makes sense.
Laurahas joined
ralphmSamWhited: it is either a documentation bug, or an implementation bug. I filed a ticket.
kaboomhas left
Ge0rGhas left
jerehas joined
Laurahello…
dwdLaura, ralphm was after the Trello board ownership.
kaboomhas left
ralphmYeah, so it turns out I am admin of the team, not the Board Meetings board.
dwdDoes MAM on MIX archive the outgoing message or the incoming one?
Ge0rGwould assume that archiving happens on the pubsub node, so only for messages reflected by the MIX
brahas left
Kevdwd: You mean pre-or-post unspecified munging, or something else?
dwdThat.
KevWhat you get out should be what would be sent to you.
KevSo if you had a pastebin running, I'd expect to get the munged URL from MAM, not the paste that I submitted.
dwdSo is the from attribute set to the MIX on the forwarded message? Does it have <jid/>? (That's what I thought... But the only example is 52 and shows the opposite).
Yagizahas joined
Steve KilleKev: yes
Steve KilleI will sort the text
Kevdwd: The from is always the MIX for MIX messages isn't it?
dwdKev, Yes. See Example 52.
mimi89999has joined
Kevby looks right to me, and from looks like a typo.
KevIs that consistent with your reading?
dwdYup. Ta.
ZashAre the to/from attributes even needed in MIX-MAM?
KevZash: Not really needed, but it's how MAM works, so there doesn't seem huge value removing them.
KevThe <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>, which is always the proxy JID, needs to be in the archived messages to say who it's really from.
KevThat's 123456#coven@mix... now, of course :)
Ge0rGSteve Kille, Kev: what about using 12345%coven@mix? It might be more in line with existing transports, that encode transported IDs by replacing @ with %
KevGe0rG: That was exactly my motivation for *not* using it (same as \), I didn't want any confusion when conflating it with existing stuff.
Ge0rGNot that I'd oppose "#", it's also used by transport JIDs (e.g. for irc: `#channel%irc.server.net@irc-transport.xmpp`)
dwdCan we have non-numeric proxy jidlets, too? (As in, in the examples - I assume it's legal)
Ge0rGKev: that's a great point
KevGe0rG: Yeah. I realised that, but it seems like the least bad option from what Steve and I discussed earlier. I'm not tied to the octothorp, other than loving the name.
vurpohas left
vurpohas joined
Ge0rGwhat about using UUIDs? *ducks&runs*
Kevdwd: That'd probably be sensible.
KevGe0rG: What, 123456<uid>coven@mix...? :)
Ge0rGKev: I had to look up into the example to determine what an octothorp is.
KevAh, 'hashtag' to you youngsters.
Ge0rGKev: no, `#<uuid>+<uuid>@uuid.server.xmpp/<uuid>/<uuid>`
ZashBRÄDGÅRD
Ge0rGKev: I'm part of the generation that associates "#" with channels, actually
Ge0rGKev: so having `#channel` in the JID rings a bell with me
KevWell, Twitter hashtags came from IRC. IRC users started using them to associate messages informally, them actually being a 'thing' came later.
Ge0rGpersonally, I liked '+' and was surprised by its demise.
ZashI thought it was meant as an inverse channel?
jerehas joined
KevGe0rG: I liked it, but + in local parts has a definite semantic from email. I felt that reversing the semantic would be confusing.
KevBut your arguments about proxypart coming first seemed compelling.
Ge0rGyay!
KevSo, changing the separator seemed sensible.
Ge0rGKev: I'm not sure if we are going to expose the proxy JIDs at all to non-tech users, and we are going to realize it's not an email anyway
KevEnd users are probably less likely to recognise the + notation than devs. It was confusing devs that I was worried about.
Ge0rGSo my vote goes to '+', with '%' a remote second.
moparisthebest+ isn't really an email standard anyway, iirc sendmail used +, and qmail or something used -
moparisthebestI have my postfix configured to accept +, -, or . as that seperator :)
Ge0rGwhat about using a slug of the user's nickname to create the proxy JIDlet?
ZashWhat if they change it?
Ge0rGZash: keep it as-is. Also if somebody tries to collide, obviously, use a different JIDlet
KevGe0rG: I think we leave choice of proxy JID parts up to the service.
KevSo if they wanted to do that, they could.
Ge0rGKev: but we could RECOMMEND something. It's not too late! :D
vurpohas left
ZashI'd also like to say that I don't think structured data belongs in jid parts, but I haven't manged to read all of MIX yet so I don't know if there's a good enough reason.
Ge0rGZash: pseudonymity combined with routability.
KevZash: I agree, in principle, but it also doesn't seem harmful, and is beneficial in this case.
Ge0rGZash: the MIX needs to provide JIDs for all resources of all participants, in a way that prevents you from obtaining their real identity
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
KevRight, the Council Trello board is now in the XSF org.
vurpohas joined
Kevralphm: Thanks for the team stuff.
jerehas joined
sezuanhas joined
Lancehas joined
vurpohas left
vurpohas joined
SamWhitedYey! Thanks Kev and ralphm
vurpohas left
vurpohas joined
uchas left
uchas joined
goffihas left
vurpohas left
vurpohas joined
ralphmhas left
vurpohas left
vurpohas joined
vurpohas left
Martinhas left
vurpohas joined
ralphmhas left
vurpohas left
sezuanhas left
vurpohas joined
sonnyhas joined
vurpohas left
vurpohas joined
SamWhitedI just discovered that Trello has "due dates". I haven't used this before. ♡
nycohas left
nicolas.veritehas left
nicolas.veritehas joined
Steve Killehas left
Steve Killehas left
nicolas.veritehas left
archas left
archas joined
waqashas joined
kalkinhas left
waqashas left
waqashas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
Steve Killehas joined
archas left
Ge0rGhas left
vurpohas left
vurpohas joined
archas joined
jonaswGuus: you wanted me to write a blogpost. I cannot recall what it was about
jubalhhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
moparisthebesthow about the meaning of life
Zash42?
Guusjonasw: anything xmpp related? :)
jonaswGuus: I cannot recall.
vurpohas left
vurpohas joined
Guusah, it was pretty obvious, actually: http://logs.xmpp.org/xsf/2017-03-13/#11:59:19
vurpohas left
vurpohas joined
jonaswoh right
Ge0rGhas left
vurpohas left
Steve Killehas left
vurpohas joined
nicolas.veritehas joined
nicolas.veritehas left
nicolas.veritehas joined
nicolas.veritehas left
vurpohas left
vurpohas joined
kalkinhas joined
nicolas.veritehas joined
Lancehas left
vurpohas left
vurpohas joined
nycohas left
nicolas.veritehas left
Yagizahas left
ZashWas there someone asking why the mam:2 namespace bump was needed?
ZashIIRC MattJ said things about security considerations that sounded reasonable. Integration with stanza-ids, and stuff.
MattJI think dwd was arguing that we should have had a "stanza-ids-are-mam-ids" feature instead of bumping the main namespace
efrithas joined
MattJThere were some other changes though (though not as many as I originally had in the doc when we decided to bump the namespace)
dwdI couldn't *find* any other changes... Might well have been textual ones.