edhelastook 10 days to turn the Facetime switch of
rionhas left
mimi89999has joined
edhelas> Weirder yet: if the recipient presses the volume down button or the power button to try to silence or dismiss the call, their camera turns on as well. Though the recipient’s phone display continues showing the incoming call screen, their microphone/camera are streaming.
jonas’amazing
edhelasthey got some pretty weird bahavior going on in their app to have that
jonas’indeed
Guus(doesn't facetime use XMPP?)
edhelasGuus in a way, everything in IM/VoiP is based on XMPP with a bit or a lot of adaptations :p
GuusYes, we can declare victory.
jonas’VICTORY
jonas’hm
GuusAlso, 2019 is going to be the year of the linux desktop.
Ge0rGGuus: the twentieth consecutive one!
GuusSee? Winning! #tigerblood
404.cityhas joined
Guushas left
GuusSee? Winning! #tigerblood
andyhas left
andyhas joined
alacerhas joined
alexishas left
alexishas joined
tahas left
andyhas left
andyhas joined
Half-ShotXhas joined
HolgerIs it known/expected that the links to Schemas in XEPs lead to a 404?
HolgerE.g. 0313 sends me to <http://www.xmpp.org/schemas/archive-management.xsd>.
jonas’Holger, known
Holgerk
goffihas joined
Half-ShotXhas left
rtq3has joined
Marandahas joined
alacerhas left
alacerhas joined
neshtaxmpphas left
neshtaxmpphas left
Guushas left
rtq3has left
rtq3has joined
mtavaresGe0rG, I've been using linux a my desktop since 1996 (almost exclusive, just a drop into win or macos every now and then), so it's more like 23th consecutive one.
alacerhas left
Half-ShotXhas joined
alacerhas joined
mrDoctorWhohas left
mrDoctorWhohas left
andyhas left
andyhas joined
alacerhas left
alacerhas joined
goffiHey, is there any reason why MAM is not activated on this room?
ralphmhas left
Half-ShotXhas left
alexishas left
Ge0rGmissing mod_mac_mum?
Marandahas joined
Marandahas joined
MarandaMac Mum 🎑✨
alexishas joined
Half-ShotXhas joined
Ge0rGMaranda: or was it mod_mum_mac?
MarandaNot sure
Ge0rGI remember it being related to a low-income overweight burger-eating family.
MarandaGe0rG, mum mac apparently
Ge0rGmaybe it was also a MILFy cam_mum.
Ge0rGThis only reinforces my wish to write a blog post: "Prosody Community Modules: The Good, the Bad, and the Ugly"
jonas’.oO(gstreamer-plugins-{good,bad,ugly})
Ge0rGjonas’: indeed.
Maranda🤔 I guess the query should be directed to Zash for a more proper naming convention on that
MarandaNaming convention discussion rather
Ge0rGMaranda: the problem is that depending on prosody version, there are modules in core or not.
Ge0rGand the core modules implement a feature set that is overlapping but neither a subset nor a superset of the community module
Ge0rGI think I need to draw plenty of Venn diagrams.
MarandaNot sure I include all modules.... Not having contributed ones
mrDoctorWhohas left
MarandaAnd since my MUC MAM relies on mod_muc_log guess what... It's called mod_muc_log_mam 🙃🤭
Ge0rGJust shuffle the letters.
Ge0rGMaranda: do you know the Kennifyer?
MarandaLike wise the http logs are called mod_muc_log_http
GuusSo, I did something silly and slapped on xep-0359 to any stanza that passed. Doesn't work to well for IQ's, which can have only one direct child.
alexishas left
Ge0rGoops
Guuswhat's the best approach here? Only Messages?
alexishas joined
Ge0rGnot doing it at all in this manner?
GuusGe0rG elaborate, please
Ge0rGI'm not sure it is a good idea to slap 0359 on *all* messages that you pass. You should only do that for messages that end up in your MAM archive
efrithas left
Guuswhat makes you wonder if it's a good idea?
dwdGe0rG, I think you *have* to place a stanza-id on anything you archive, with mam:2. Whether you *also* place them on other messages is not specified.
dwdGe0rG, But a client might ask for "all messages after this one", so if you can't service that from MAM because you're unaware of the stanza-id referenced, that could be a problem.
Ge0rGdwd: that's exactly what I was thinking. CC Guus
dwdAlso, there's a nagging concern that if you're a little over-zealous in archiving messages, you can archive the MAM result stanzas, and a query for "every message after this point" can lead you into some interestingly endless interactions.
ZashNo
ZashThose would be contained inside forwarded-containers, right?
Ge0rGZash: it's not *forbidden* to archive those.
Ge0rGI'm not sure whether it was mentioned before, but it would be nice to have consistent rules for MAM and Carbons and ephemeral vs. persistent messages.
ZashYes
ZashSomething for the summit perhaps?
Ge0rGFor the 2018 Summit.
ZashYou know all these issues stand still while there isn't an ongoing summit :)
Ge0rGI'd like to have Summit discuss the mess of message IDs, and which ones to use when when referencing messages.
Ge0rGZash: because nobody reads the ML?
ZashNobody reads anything, ever :)
edhelashas left
Guusan awesome tagline for a chat client.
edhelashas joined
alacerhas left
alacerhas joined
dwdGe0rG, Might it be worth looking at XEP-0226 again and seeing if it makes sense to stipulate ephemerality in terms of message profiles?
Ge0rGdwd: interesting idea, but I fear it will lead into an endless list of exceptions and exceptions-from-exceptions
Ge0rGdwd: essentially you'd end up codifying the existing rules with a different name
dwdGe0rG, Well, the existing rules are "apply common sense".
Ge0rGdwd: that doesn't work
Ge0rGIt's a good way to delegate the hard work from people who should know it to random server developers.
dwdGe0rG, I think we can approach this by saying "these elements are metadata - ignore them for the purposes of MAM/Carbons/etc", and "these elements mean it's worth doing something with".
dwdGe0rG, In general, server developers are not random. Certainly not cryptogrphically so.
Ge0rGdwd: ah, so you are into tagging stanza elements and using those as signal/noise indicators?
GuusI'd not consider myself to be a cryptographically strong random, but more random like https://xkcd.com/221/
dwdGe0rG, I'm into exploring the idea, certainly. That's the approach of XEP-0226 - to use the elements as contents (and, in this case, ban certain combinations).
sezuanhas left
dwdGe0rG, Also, same, but in my case with a loaded dice.
Ge0rGdwd: what you propose sounds like a formal notion (with explicitly named elements) of https://op-co.de/tmp/xep-0280.html#which-messages
Ge0rGdwd: while I was more interested in changing the semantics of either message type, to-JID-fullness or both, to encode the ephemerality. Hence IM-NG
sezuanhas left
rionhas left
dwdI think that's a waste of effort. It's a boil-the-ocean forklift upgrade.
dwdI mean, those are great fun, but they've repeatedly failed.
Ge0rGdwd: I'm not convinced it actually is.
rionhas joined
Ge0rGdwd: my ideas are 90% compliant with 6121 rules
Ge0rGBut yeah, I have ambitious goals.
Ge0rGI need to restrain myself. Can we please get Summit to at least figure out which of the (only?) three message identifiers are to be used when?
dwdAmbition is laudable, but we need a touch of pragmatism too.
ZashHints?
dwdGe0rG, Three? Origin, Stanza-id, and id attribute?
Ge0rGdwd: yes
dwdZash, Council shot down hints. I didn't agree, and still find it very useful.
Ge0rGIIRC, Council's problem was that the XEP format is not suitable for Hints.
Ge0rGMaybe there should be a Registry of Hints instead?
dwdGe0rG, Yes indeed. I think if origin isn't the same as the id attribute something has borkened, and stanza-id is for ids applied by intermediates (and used when querying those intermediates).
dwdGe0rG, I thought there were multiple arguments against hints, like servers might ignore them and things.
Ge0rGdwd: but which one do you use in 0184 ACKs? Which one in 0333? Which one in proto-XEP-emoji-Reactions?
Ge0rGdwd: yeah, those too
dwdGe0rG, The first two are specified as the stanza's id attribute, aren't they?
Ge0rGdwd: that doesn't mean it's right, just that they predate 0359.
Ge0rG@id is optional and scoped on the c2s stream, so there are no uniqueness guarantees. origin-id can be forged by a malicious client, and stanza-id isn't available until the message was reflected to you, which is "never" in the default case.
dwdGe0rG, Let me rephrase - I think origin-id is an unfortunate workaround for broken behaviour, some of which I even contributed to.
Ge0rGdwd: okay okay. I'm writing up the long version to standards@
dwdGe0rG, Rather than ossify it, I'd rather treat it as the workaround it is, and work to remove the requirement for its existence.
Ge0rGdwd: there is a principal problem with attager-generated-IDs scoped to a MUC (as opposed to a direct chat)
Ge0rGdwd: there is a principal problem with attacker-generated-IDs scoped to a MUC (as opposed to a direct chat)
dwdGe0rG, Does origin-id help with that at all?
Ge0rGdwd: no
Ge0rGit merely adds to the confusion
lnjhas joined
moparisthebesthas left
dwdGe0rG, Right. Of course, if MUCs *don't* preserve ids, then the reflection would ... Oh.
Ge0rGdwd: oh?
dwdGe0rG, That is, the attack is only even vaguely possible because an attacker has control of the id. If the MUC re-issues a new id, then it's largely moot.
Ge0rGdwd: yes, you have replaced a reference authentication problem with a race condition problem.
mightyBroccolihas joined
equilhas joined
andyhas left
andyhas joined
404.cityhas joined
MattJhas joined
j.rhas left
j.rhas joined
alexishas left
alexishas joined
MattJhas joined
Half-ShotXhas left
Half-ShotXhas joined
tahas left
Half-ShotXhas left
lhas joined
alexishas joined
alexishas left
alexishas joined
Half-ShotXhas joined
Tobiashas joined
alexishas joined
vaulorhas joined
equilhas joined
alexishas joined
j.rhas joined
j.rhas joined
alexishas left
alexishas joined
Half-ShotXhas left
Half-ShotXhas joined
Half-ShotXhas left
Half-ShotXhas joined
vaulorhas joined
Alexhas joined
goffihas joined
Half-ShotXhas left
equilhas joined
Half-ShotXhas joined
Half-ShotXhas left
frainzhas left
labdsfhas left
labdsfhas joined
pep.has joined
Half-ShotXhas joined
Half-ShotXhas left
Alexhas left
andyhas left
andyhas joined
andyhas left
andyhas joined
lumihas joined
efrithas joined
Alexhas joined
Half-ShotXhas joined
sezuanhas left
efrithas joined
Nekithas left
Nekithas joined
alexishas left
alexishas joined
Half-ShotXhas left
Half-ShotXhas joined
rtq3has joined
Half-ShotXhas left
Half-ShotXhas joined
Half-ShotXhas left
flowIs there a canonical XMPP logo somewhere?
ZashYes
jonas’flow, any of xmpp*.png in https://github.com/xsf/xmpp.org/tree/master/content/images/logos ?
Half-ShotXhas joined
ZashNo .svg?
jonas’somewhere
jonas’haven’t found it yet
Zash`$ locate xmpp.svg`
jonas’flow, https://github.com/xsf/xmpp.org/pull/363 Guus probably knows where the SVG version is
Guusspeaking of which - did Peter get back to you?
Ge0rGGuus: not yet
Ge0rG> Will reply tonight or tomorrow!
-- Thu, 24 Jan 2019
mightyBroccolihas left
efrithas left
Ge0rGGuus: should I ping him?
Half-ShotXhas left
Half-ShotXhas joined
Ge0rGdwd: I'd like to conclude the 0410 LC with a Council vote, but there was an intersting issue brought up and not yet resolved: should there be an _additional_ error condition that says something like "you are not a participant to this MUC"?
Half-ShotXhas left
andyhas joined
jonas’Ge0rG, I think we need to have a second round of LC after you updated the XEP
GuusGe0rG I just pinged Peter
Guuswraaaagghhh why can't I type on three keyboards at the same time.
Ge0rGGuus: thanks very much
Ge0rGjonas’: but why?
jonas’ah, no
jonas’it is indeed a council vote which is the next step
jonas’you do updates, council votes whether to decide on it now or have another LC
jonas’XEP-0001, §7
> Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.
Ge0rGjonas’: so the options are now:
- merge the PR and let the Council vote on Proposal
- try to gain more feedback and resolve open questions
mightyBroccolihas joined
jonas’maybe
jonas’I’m too full of cold slime to figure that out at the moment
Ge0rGmy gut feeling is that there are two issues worth delaying the Proposal: the additional error condition; and the correct baseline IQ response for a non-participant
jonas’yes
jonas’I suggest that you make an update to the PR which incorporates what you’d like them to be and we can discuss that tomorrow and decide whether we find it okay enough or put it into another LC?
dwdGe0rG, "occupant", but yeah.
dwdneeds to do the agenda in a bit, and will try to remember to put it on.
Ge0rGParticipant: An occupant who does not have admin status
Ge0rGEw.
dwdI thought a particpant had voice, as well.
Ge0rGdwd: I don't feel ready for Proposing yet.
Nekithas left
Nekithas joined
jonas’the key question is, do you have a ring yet?
Link Mauvehas joined
Link Mauvehas joined
Ge0rGjonas’: a jingle ring or a token ring?
jonas’a facetime ring, maybe
Ge0rGone ring to spy upon them
jonas’:>
Half-ShotXhas joined
Half-ShotXhas left
Kevhas joined
Half-ShotXhas joined
Guushas left
frainzhas left
Ge0rG> The <error/> element:
> - MUST contain a defined condition element.
> - MAY contain a <text/> child element ...
> - MAY contain a child element for an application-specific error condition
Is it allowed to have multiple application-specific error conditions? Multiple defined condition elements?
XSF Discussion - 2019-01-29