zeankHidiho! In the light of Push Notifications I wondered if it wouldn't make sense to add a <no-push xmlns="urn:xmpp:hints"/> to https://xmpp.org/extensions/xep-0334.html ?
rionhas left
Ge0rGzeank: where should it be used, then?
nycohas joined
zeankTo not trigger a push on the server side
Tobiasand you want remote parties in control of that?
zeankin certain cases, yes
zeankOk, I see a problem … they could control it all then :/
nicolas.veritehas left
Tobiaszeank, what cases are those?
zeankin our scenario we exchange let's call it meta information between clients
zeankas messages though
zeankand we don't want to trigger a push for those
KevServers need to not act on hints, because you almost never want a remote client being able to tell your server what to do about things like storing or copying or pushing.
zeanktyping notifications could be another
Tobiaswhy would servers trigger push notifications on body-less messages
ralphmhas left
blipphas joined
zeankhm, fair point in our case all messages are body less because they are encrypted and have no body in general
zeankit's a proprietary system
zeankjust thought it might be useful for others as well
zeank@Kev so the whole XEP is wrong?
Ge0rGI think we need a common ruleset for decisions about pushing, carbon-copying and MAM-archiving of messages.
Kevzeank: I thought 334 said that they were just hints, and entities didn't have to honour them.
Ge0rGKev: the alternative would be to encode stateful processing rules in the server, right?
KevBut if it really says that a remote client can choose whether my server puts things in my archive, then yes, it's of limited applicability (rather than wrong, as it might still be useful in closed systems), and we need to be very careful about anything depending on it.
zeankyes, they are just "hints", but they are targeting the behaviour of the server, not sure how push and MAM are so different in this regard then
sonnyhas joined
kalkinhas left
Tobiaszeank, that proprietary system sounds interesting if it can encrypt even typing notifications, which OMEMO currently can't afaik :)
kalkinhas joined
zeankwe don't have typing notifications yet, just to be clear ;)
Tobiasis much less excited now
zeank:p
Ge0rGKev: do you happen to have an idea how to make the desired functionality of hints secure and proper, in the context of the right trust boundaries?
Laurahas left
Laurahas joined
KevGe0rG: Put the rules in the server not the remote client, is all I have.
mhterreshas joined
HolgerAs for the copying of messages, doesn't XMPP core allow the sender to control this by addressing the full vs. bare JID and using certain message types?
KevWhat gets archived by the server is very clearly a server decision, not a remote client decision.
KevHolger: Not with carbons.
Tobiasright, but there are currently few sensible guidelines on that, not?
Ge0rGKev: "A message of type 'chat' is not eligible for carbon copies if it contains a body and the body starts with the verbatim string '?OTR'"
HolgerYes then XEP-0280 breaks this, which is why we need hints for that :-)
zeank:p
Ge0rGHolger: actually, the remote party can only choose between "deliver to THIS resource" and "deliver to somebody implementation-defined"
HolgerSure.
Ge0rGand I really despise the last part of it.
HolgerI think the desired behavior is to be able to address either an individual device or the account.
Ge0rGbecause you can't rely on it, but you need to for a proper notification implementation.
jonaswwe could all agree that "somebody implementation defined" is "nobody, but everyone interested gets a carbon copy" :)
jerehas joined
Ge0rGjonasw: that makes sense if all your clients enable carbons and if you make no client-side semantic difference between "real" messages and carbons
Ge0rGjonasw: but the latter will bite you in a multi-client context.
Ge0rGe.g. in the "I have my phone on the desk and use my desktop" user story.
jonaswGe0rG: you need to solve that anyways, no matter if you CC everything or not
nicolas.veritehas joined
jonaswbecause the user can switch at any point in time
Ge0rGjonasw: yes, but you can use carbons as a hint
jonaswfor the former part: clients who cannot into CC are annoying anyways and they’re gambling on whether they get messages or not as-is
jonaswGe0rG: but you depend on the server implementation-defined mess if your peer always addresses the bare JID like your client does ;)
nicolas.veritehas left
jonaswI’d rather use xep 84 as a hint actually.
Ge0rG> clients who cannot into CC are annoying anyways
said the pidgin user
jonaswyes, that means that I must know, Ge0rG.
Martinhas joined
narcodehas left
Martinhas left
Ge0rGIt's obviously getting complicated and complicated, on the client side. This is the opposite of the general idea of XMPP, but we could do something like this:
on received message:
if (message is carbon or sent to bare JID) and (we got presence/activity from another resource of our account recently):
delay notification by a 1-minute timer which is cancelled on activity from another client
Martinhas joined
HolgerConversations does the "we got presence/activity from another resource" check.
Laurahas left
Ge0rGHolger: Conversations does many things that are not codified. While this is good for Conversations users, it makes it harder for future client implementations
HolgerA better solution might be looking at the CSI state. Then again, at least desktop clients probably just don't have a good idea of whether they're currently active or not.
Ge0rGWhat about just reading tea leaves?
KevI think 'implement Kev's upcoming read-sync XEP' might be a good approach ;)
KevI really need to write something there, though :/
TobiasGe0rG, that won't float well with coffee enthusiasts
Manchohas joined
Ge0rGTobias: they wouldn't even notice, if we provide centralized access to tea-leaves-entropy. Otherwise, we'd need to kindly ask the user to make a photograph.
blipphas left
blipphas joined
kaboomhas left
kaboomhas left
nycohas joined
kaboomhas left
kaboomhas left
kaboomhas left
goffihas joined
rionhas joined
efrithas joined
goffihas left
goffihas joined
jubalhhas joined
jubalhhas left
nycohas joined
Ge0rGKev: the read-sync sounds like a more explicit way to tell other clients that messages have been read. I'm not sure if it will also help in the notification-delay/prevention situation
KevWell, it helps, because it's an explicit way of knowing that a message doesn't need to be notified (or that a notification can be cleared), but it doesn't prevent you needing some logic somewhere about delaying notifications, indeed.
KevI think that's just the cost of doing business.
Ge0rGKev: will it be similar to chat state notifications?
KevNot particularly, no :)
kaboomhas left
efrithas joined
nicolas.veritehas joined
nicolas.veritehas left
Valerianhas left
Valerianhas joined
Valerianhas left
kaboomhas left
mhterreshas left
Guushas left
lloydwatkinhas joined
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
Ge0rGKev: why not?
KevBecause CSN go to the other party, and read sync goes to your server, and from there to your clients?
Ge0rGHm. So it's an account-centric thing.
kaboomhas left
KevYes.
jonaswKev: you could send CSN to your own bare JID :-)
jonaswand let carbons do the rest
Ge0rGjonasw: it would get reflected to yourself.
jonaswexactly
Kevjonasw: That doesn't work for saying which messages are read, though.
Ge0rGthere is no xmpp primitive to "send something to all the other clients of yours"
jonaswKev: yes, but isn’t there something for that already?
jonaswGe0rG: ah, that’s what you mean
jonaswGe0rG: well, we may need one
Ge0rGone could use PEP
jonaswugh
TobiasGe0rG, with carbons there is, not?
jonaswTobias: all *other* clients
Ge0rGTobias: what'd be your destination JID? the server?
TobiasGe0rG, your own bare JID? :)
Ge0rGmessage to "account-domain.xmpp" would get carboned to all other clients
Ge0rGTobias: no. you'd get the message twice
jonaswon each resource (once as <sent/>, once as <received/>)
Ge0rGTobias: first the 'sent' carbon, then the delivered message/carbon
Ge0rGexcept on the sending client, it would only get one copy
TobiasGe0rG, "at least once" semantic is easier than "exactly once"
Ge0rGTobias: but using the "most probably twice" semantics is just wrong.
HolgerWhat's wrong with PEP BTW?
jonaswredundancy!
nicolas.veritehas joined
nicolas.veritehas left
suzyohas left
suzyohas joined
kaboomhas left
nycohas joined
kalkinhas left
kaboomhas left
kalkinhas joined
lskdjfhas joined
kaboomhas left
kaboomhas left
kaboomhas left
nycohas joined
kaboomhas left
Manchohas left
Alexhas joined
nicolas.veritehas joined
Alexhas left
Holgerhas left
nicolas.veritehas left
lskdjfhas left
Tobiasand that would be the last XMPP related fosdem talk tweeted about
kaboomhas left
Guuswhich reminds me: we could use a new post for the blog. Anyone interested in writing one?
sonnyhas joined
sonnyhas joined
nicolas.veritehas joined
Ge0rGGuus: what should it be about?
kaboomhas left
TobiasGe0rG, federal reserve, rainforest, and that sort of thing
Ge0rGTobias: xsf world domination plans? Because it's a greater challenge if we announce the plans in advance?
nicolas.veritehas left
Tobiaswe already have a retracted XEP for that :P that should be enough of an announcement
kaboomhas left
kaboomhas left
kaboomhas left
Valerianhas joined
nycohas joined
Ge0rGRetracted? People don't even care about experimental...
kaboomhas left
GuusGe0rG: I have no specific agenda, other than trying to help make sure that the blog gets regular updates. So far, I've reached out to Daniel for an OMEMO post, and Rikard for an IoT one.
Tobiaswell..it's kind of hidde
Tobias*hidden
kaboomhas left
Yagizahas left
GuusIf you have a good idea, feel free to submit something. You can easily add a blog post via a PR on the website, or send it to me by text, and I'd be happy to post on your behalf.
TobiasGe0rG could write about how snarky comments in open standards communities result in improved protocols ;)
Ge0rGGuus: sounds good to me. I'm sure nobody wants ME to write a guest post.
Tobiasor more seriously, about his efforts on improving UX and usability
GuusGe0rG: guest? you're a member, right?
Ge0rGGuus: right. But I'm not a regular contributor to the blog.
Ge0rGTobias: im sure that would get flagged immediately because of neutrality concerns.
TobiasGe0rG, a blog without regular posts doesn't have any regular contributors at all
TobiasGe0rG, we could neutralize it
GuusGe0rG: I wonder if anyone considers themselves a 'regular blogger' here. There's people that posted more than others, but that's more because of a lack of input by the others. :)
nicolas.veritehas joined
Ge0rGTobias: also, what would be the target audience? It seems that it's widely irrelevant to users, and there are two camps of developers: the ones who don't care, and the ones who have no time to improve
Tobiasyeah...try to channel that optimism into words for the blog post
nicolas.veritehas left
Guus(no response, which presumably means he's drafting a post!)
Guuseyes dwd
Ge0rGI feel a bit like Aragorn, having his motivational speech before the fight of helm's deep. Except there is no army. Actually, now that I think of it, it's probably more like Tyrion Lannister's "don't fight for your king" speech.
Guusso, you're good with words...
GuusGe0rG: You might be making a bit to much of it :)
nycohas joined
Ge0rGGuus: this is probably a sign that I'm overqualified ;)
GuusGe0rG: Perhaps. You should take this as a challange to see if you can lower yourself to our level!
TobiasGe0rG, it might result in more users demanding better usability for their clients, who knows
vurpohas left
Ge0rGTobias: quite seriously, I'm not sure how to frame the whole thing. "Here is this new set of ideas how to make XMPP better"?
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
Ge0rGTobias: the obvious question for the readers would be "why are they talking about it, instead of just doing it"
GuusGe0rG: perhaps frame the fact that we need a solution for a probem? "Clients look aweful, we could use an effort to stream line things. We've started doing that at xyz"
Guus(but nicer)
vurpohas joined
TobiasGe0rG, well..it makes little sense talking here about it, as you already made your point and few new people come here
vurpohas left
Tobiasi think our blog has a wider target audience than this room
dwdAlso more tweetable.
GuusTobias: do you have access to pageview stats?
Tobiasno
vurpohas joined
Tobiasi'd also would like to have access to xmpp twitter account analytics...to see if all that tweeting increased out followers (it did, but how much)
Ge0rGGuus: the next problem is: I'd really like to use specific examples of how things can be improved, namely conversations and (to a degree) yaxim. But then it'd result in something like https://yaxim.org/blog/2017/01/31/yaxim-0-dot-9-security-easy-xmpp/ and obviously violate XSF neutrality in a way that's hard to neutralize
vurpohas left
GuusGe0rG: I'd almost consider that a follow-up post. I'm not to bothered by the neutrality thing (but others disagree), but, referencing to Yaxim as an example should be fine I think - more so if you can reference another implementation too
vurpohas joined
vurpohas left
vurpohas joined
Ge0rGI fear that even mentioning https://github.com/ge0rg/easy-xmpp-invitation which is really client-agnostic (except for the hardcoded list of yaxim+conversations) would be seen as a violation
GuusThere's always goign to be someone that sees something as a violation of something. If that stops people, nothign would get done.
jonaswGuus: +1
Ge0rGGuus: I just extrapolate the previous feedback I've received from XSF members to my public statements about the state of XMPP.
Ge0rGGuus: if I disregard that, I can imagine writing a call-to-action post about Easy XMPP. And I'll try hard to make it as positive as possible
GuusGe0rG: you might generate more feedback than others here :)
Ge0rGGuus: I'm not sure if the feedback I generate is of the right sort.
vurpohas left
vurpohas joined
GuusGe0rG: I'd love for you to draft a rough outline of a post. We can do a PR on that, and have some reviews.
Ge0rGGuus: deal
Guusawesome, thanks!
Guusand again - I think it might be a good idea to smear this topic out over a couple of posts. One that describes the problem and the approach taken to start working on a fix - another one that describes a few of the fixes, and more that illustrate how individual implementations are now improved. Then, a final one where you claim victory.
danielhas left
GuusGe0rG: there might be a handful of posts and world dominition in this for you ;)
danielhas joined
Ge0rGGuus: I don't aim for world domination
Ge0rGGuus: all I want is a nice big yacht. :D
vurpohas left
vurpohas joined
GuusGe0rG: if you want, I can put you in contact with one of my Nigerian royal friends who badly need to transfer money out of the country? Supposedly, that's a win/win and risk-free.
Ge0rGGuus: I think I'm already in negotiations with that person
jonasw:)
GuusGe0rG: I am sure then that your ship will litererally and figuratively come in any minute now.
vurpohas left
GuusTobias: could you do a review of https://github.com/xsf/xmpp.org/pull/185 ?
GuusI think it's ready to merge now (finally)
Tobiaswill do this evening
vurpohas joined
GuusThanks
vurpohas left
vurpohas joined
jonaswis my dynamic list generation code live already?
Guusjonasw: I think so, yes.
jonaswthen we can start the attack on the quality of listed software, right?
GuusI fixed the problem that prevented a bunch of commits to go live, after which the changes that were visible to me popped up.
jonaswwith requiring projects to re-request their listing and so on
Guusjonasw: I see a blogpost in your immediate future :D
jonaswI’m super tired right now, not sure if writes to my task memory persist currently :)
Guusno worries, I'll be here to haun...remind you.
Yagizahas joined
Yagizahas joined
Ge0rGGuus: https://github.com/xsf/xmpp.org/pull/274 - I'm sure this will ignite a discussion.
vurpohas left
vurpohas joined
vurpohas left
intosihas left
vurpohas joined
suzyohas left
blipphas left
Yagizahas joined
intosihas joined
danielhas left
sonnyhas joined
danielhas joined
sonnyhas joined
kalkinhas left
kalkinhas joined
Yagizahas left
Flowhas joined
Alexhas joined
GuusThanks Ge0rG. I responded on github
Yagizahas joined
Ge0rGGuus: the verbatim tldr will get out, but I'm used to make the first paragraph of long posts effectively a tldr
suzyohas joined
GuusGe0rG: that might be a sign that the text is to long for a blogpost :)
Guusbut, a matter of personal preference, probably
GuusMy main point is that I really dislike 'tl;dr'
Ge0rGGuus: I'd say it is a sign of respect to the prospective reader. I tell them in a single paragraph if the remaining part worth reading.
Ge0rG*is
Guuspersonal preference. :)
Guusgo for it - it's your text.
Flowhas left
Ge0rGGuus: thanks for your feedback. I'll update the pr when I find some more time
blipphas joined
Zashhas joined
Alexhas left
Alexhas joined
Alexhas left
uchas left
uchas joined
mimi89999has joined
Yagizahas left
mimi89999has joined
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
intosihas left
kaboomhas left
jonaswGuus: you could call it "Abstract", is that better?
intosihas joined
Ge0rGjonasw: what's wrong with an implicit "summary"
jonaswI don’t know.
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
mimi89999has left
Alexhas joined
bjchas joined
mimi89999has left
bjchas left
bjchas joined
mimi89999has joined
mimi89999has left
mimi89999has left
mimi89999has left
kaboomhas left
bjchas left
bjchas joined
kaboomhas left
kaboomhas left
kaboomhas left
Valerianhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
winfriedhas left
kaboomhas left
kaboomhas left
dwdSo... The only point where mam:2 makes any difference is in the one place where the XML namespace is not used.
Holgerhas left
Holgerhas left
nycohas joined
nicolas.veritehas joined
dwd... and this has no impact *at all* on MIX.
nicolas.veritehas left
kaboomhas left
lskdjfhas joined
mimi89999has joined
kaboomhas left
Holgerhas left
mimi89999has joined
mimi89999has left
jerehas joined
kaboomhas left
mimi89999has joined
kaboomhas left
Yagizahas joined
kaboomhas left
kaboomhas left
kaboomhas left
Yagizahas left
Alexhas left
Alexhas joined
Yagizahas joined
Tobiashas joined
Holgerhas left
Zashhas left
Zashhas joined
Manchohas left
Holgerhas left
Holgerhas left
Alexhas left
bearhas joined
waqashas joined
jerehas joined
KevQuestion, UX experts.
Valerianhas joined
KevHypothetically if you were writing an XMPP client and wanted the experience when opening a chat from within a MUC to not suck (i.e. to open to the real JID instead of the room JID) in the usual case, how (if at all) would you protect it against spoofing on untrusted remote MUC services?
jerehas joined
lskdjfhas left
Ge0rGKev: you are talking about private chats?
dwdHypoethetically, if I were using an untrusted remote MUC service, how stupid would I be to be sending it messages anyway?
KevIt depends on the trust, I think?
Ge0rGwith my UX hat: I'd just open a chat wit the bare JID advertised in the MUC.
with my security hat: what dwd said.
dwdKev, What are you trusting it to do and not do?
KevI mean, I may trust my inane discussions to something, but not want it to be able to lie about someone's real JID and have me spam a helpless person directly.
Ge0rGKev: this is the same security concerns I'm pondering about for some weeks already, in the context of mediated vs. direct MUC invitations
dwdKev, That's not a security concern.
KevTurning occupants into a DDoS probably is :)
dwdKev, That's a concern you might annoy someone, not a concern about leaking information.
KevI don't think I said anything about it being a concern leaking information, did I?
Kev(Or even security)
dwdKev, Hardly; you're reliant on having users PM people. And if you're a remote MUC, you can spoof the PMs directly, causing people to get any responses.
KevYou can't spoof the PM as being from my server, though.
dwdKev, No, but I can spoof them as being from you, via a MUC.
KevYes. I'm thinking about people not in the room at all.
dwdKev, Who isn't in the room?
KevYou annoy me, so I tell all jabber.org MUCs to say that every occupant's real JID is yours, and then you get spammed every time someone tries to send a PM.
dwdKev, That was you?
dwdKev, You git.
KevI do.
KevAlthough I don't tend to use it as a verb.
jonaswhas left
KevRegardless, this feels like it might not be ideal, to me.
dwdKev, True, that would be subversion.
KevVery good.
jonaswhas left
dwdKev, OK. So I think the "real-jid" issue here remains irrelevant. It's one case where a (popular) MUC service could abuse trust.
KevI'm pondering possible options being "Meh, you're in the MUC, you're showing some trust", "Do it if it's someone in your roster" (so you can probably work through the social issue if it gets spoofed), "do it if it's a local service". (where 'it' is opening to the real JID).
Ge0rGKev: I think the only sane solution to that is having MUC presence signed by the user's account key.
KevThere's also revealing your own JID in the case that you're a moderator in a room.
dwdGe0rG, Seems fair.
ZashHow do you know what account key is the right one?
dwdKev, I think any of your options is fine.
KevCertainly the irritation of having PMs outside your normal flow is significant and I want to fix it.
dwdZash, By asking the MUC for the public key of its occupant of course. Duh!
ZashMUC can't lie
SamWhitedMUC real-JID dial-back verification? When you want to verify a JID in a MUC you send them a token (through the MUC), and then they echo it back via their real-JID. I'm not sure this is necessary either, but it's fun to think about.
dwdZash, Evil-MUC-bit?
Ge0rGZash: you query the bare JID for a signed presence, or check your roster
KevSamWhited: Sure, but that only works if you've running over jidnssec, which no-one is :)
Ge0rGKev: may I point you to https://mail.jabber.org/pipermail/standards/2017-January/032021.html
SamWhitedKev: jidnssec? Not sure if real thing or a joke I didn't get…
Tobiasit's a DNSSEC deployment joke
SamWhitedOh, heh, right
KevSamWhited: It's a joke. You mentioned dialback, which is a fine thing to use for S2S as long as you have dnssec.
nicolas.veritehas joined
dwd(And you also use TLS).
nicolas.veritehas left
Tobiasand .im domains can't do DNSSEC because people from the isle of man are afraid of locsk
Tobias*locks
SamWhitedI think it works in this case though if you trust the s2s connection at all
SamWhited(the s2s connection doesn't have to do dialback, I just used that name because they're echoing an HMAC or something back at you)
KevYes, it's not a stupid idea.
SamWhitedYou'd have to do it two ways though for mutual verification, so there's probably a better way
Ge0rGSamWhited: like... distributed MUCs
Ge0rGor maybe we need to replace JIDs with pubkey-based identities
SamWhitedGe0rG: I'm assuming this was a question for a MUC implementation today, not for a future-widely-used-thing implementation.
ralphmhas left
Ge0rGor we just ignore the problem and pretend it doesn't exist.
ZashLet's build an elaborate PKI!
ZashThe world needs more of those
Ge0rGOr we introduce a "security level slider" into our apps, ranging from "I don't care, just make it work" to "I'm ultraparanoid"
Kev(And thanks all, BTW)
dwdGe0rG, Excellent. The world need more security options that users don't understand the implications of.
Ge0rGKev: so have you come to a conclusion how to do it?
ZashGe0rG: Key based identity would be interesting, but I don't think that's even XMPP 2, that's gotta be something completely new.
Ge0rGdwd: most users don't understand the implications of any of the security options provided to them.
KevGe0rG: I think the conclusion is "Meh, just do it"
Ge0rGZash: TOX maybe. It's got an "X" in it at least.
Ge0rGKev: this conclusion was also reached at the end of the lively security debate in the thread I pointed to.
KevFWIW, for mediated invitations, Swift shows it but warns that it could have been spoofed.
KevI can't remember if we replied to the thread or not.
Tobiashas left
KevBut the whole mediated invite thing is horrid anyway and everyone needs to just use direct invites :)
Ge0rGKev: direct invites don't auto-add the receiver to the MUC affiliation
nicolas.veritehas joined
mimi89999has joined
TobiasGe0rG, jet fuel can't melt steel beams
TobiasGe0rG, i think setting up specific affiliations for participants is a quite rare use case
nicolas.veritehas left
nycohas left
Ge0rGTobias: I want to have a private group chat with my family members. Do you have an idea of the steps I have to perform to achieve that, client-side?
Ge0rGHint: none of them are described in 0045.
KevGe0rG: You open Swift, you choose 'start chat' and drag all of them into it? :)
Tobiasjust create a UUID MUC and invite the people you want to join
Ge0rGTobias: but I need to make that MUC invite-only and hidden.
Ge0rGI think there are some forms to enable that.
Tobiashidden yes, invite-only (why, who will know the JID?)
vurpohas left
Ge0rGTobias: and then I need to add all the folks into the affiliation
vurpohas joined
Tobiashas left
Ge0rGTobias: so you are using the JID as a password?
tim@boese-ban.dehas joined
Tobiasbasically, yes
Ge0rGAm I the only one who thinks this is significantly worse than following invites from a remote untrusted MUC?
TobiasGe0rG, what's your fear? people guessing the JID? that one of the participants leaks the JID?
Ge0rGTobias: accidental leaking of the JID
Tobiashow?
Ge0rGTobias: pastebinned client debug logs, server bugs
Tobiaswhat says the way you'd accidentially leak your JID wouldn't also leak the password if it were password protected?
Ge0rGTobias: JIDs are not generally considered "secret"
Ge0rGTobias: by violating that assumption, you are bringing your users one step closer to the abyss
Ge0rGTobias: leaking a password requires gross negligence
SamWhitedUser probably shouldn't see or know that a JID exists (especially if it's really just a UUID), so I don't see why it matters.
Tobiaswell...if you want to provide a true sense of security to your users you should do OMEMO in the MUC anyway
Ge0rGTobias: my point is that it's good to have additional guards
Ge0rGand "closed affiliation" is one such
mimi89999has left
mimi89999has joined
Ge0rGhas left
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
HolgerTobias: For OMEMO you want to have the group members affiliated with the room anyway, though :-)
HolgerAnd simply for listing the offline members of your group chat.
HolgerAnd because you want that anyway, you can just as well make the room members-only (since *this* step is simple).
Tobiasi wish there were a XEP for taht
Tobias*that
HolgerFor what?
Alexhas left
Ge0rGHolger: for creating a members-only private MUC, I suppose
Ge0rGI'm going to add that to yaxim soon, and write it down in the process. I'm interested in such an XEP as well
Ge0rGSufficiently interested to actually write it, if nobdy else *cough*daniel*cough* jumps in.
Ge0rGhttps://wiki.xmpp.org/web/Easy_Group_Chats is the first iteration
Ge0rGI've had another crazy idea: to use the "long description" of the MUC to store a link to an http-uploaded avatar
HolgerI think it's all in 0045 even though it wasn't written with that use-case in mind.
Ge0rGHolger: you must be talking of https://xmpp.org/extensions/xep-0045.html#createroom-instant
Holger(Except for an option to enable MUC MAM for servers who want to make this configurable.)
HolgerGe0rG, no I wasn't suggesting an instant room. Maybe I'm missing something but what I have in mind is simply using a plain members-only room with MAM for private/presence-less group chat.
Ge0rGHolger: and where is that written down in the XEP?
Ge0rGI'm not quite sure what the use case of the 0045 "instant room" is, except for being comparably bad to instant soup.
HolgerOnly the building blocks are there of course. It doesn't say "to create a private group chat, do this and that".
Ge0rGHolger: but I want it to be in there.
Ge0rGHolger: your statement is comparable to "all the building blocks for a group chat are in rfc 6120+21" :P
HolgerGe0rG: I don't think that's comparable; 0045 adds protocol on top of the RFCs while my point is that you don't really need anything on top of 0045. But I see how a document explaining how to use 0045 to implement group chat would be useful.
SouLhas left
Ge0rGHolger: I would even 1-up that and say that 0045 should contain it
Ge0rGmaybe the council will not be strictly opposed to adding a new informational section to 0045
HolgerAnd maybe #204 should be sorted out first as well :-)
BunnehHolger: XEP-0045: Define option name for enabling/disabling MAM #204
https://github.com/xsf/xeps/pull/204
suzyohas joined
Ge0rGHolger: btw, being a server developer. Would you rather prefer more rules in 0280 clarifying what to do with [xep 0184] acks and [xep 0333] states, or have those two contain explicit <copy> hints?
HolgerI think adding more rules to 0280 modules is wrong.
Zash+1
MattJ+2
jonaswhttps://xkcd.com/1810/ is sad.
intosi+3
Alexhas joined
Ge0rGcase in point: 0184 does not mandate to use type=chat
Viniloxhas left
HolgerIndeed. I use local patches that add rules to fix such things :-/
Ge0rGbut Kev said that we shall not rely on remote clients telling us what to do
HolgerAnd I disagree, at least when it comes to addressing accounts vs. individual devices.
dwdhas left
SamWhitedDoes anyone here have any idea how communication with IANA should work? I've been googling things like "IANA registration procedure" and "IANA expert review rules" and so far everyting is completely undocumented and worthless as usual… *grumble, grumble*
ZashEmail someone. ???, PROFIT!
SamWhitedI found one old document that explicitly said that IANA procedures were currently not documented, so I'm just about ready to assume taht's still right, everything is tribal knowledge, and then just start spamming people until someone updaets the registry.
Guushargh - the US went to/from DST?
intosiYup.
zeankhas left
SamWhitedGuus: Yup; be warned, everyone on this side of the pond is confused and grumpty today (actually, that's most days, but *more so* today)
GuusWhich explains why this meet is pretty empty...
intosiThey probably measure DST in furlongs per fortnight or something.
GuusIt's bad enough that we have DST in the first place - but everyone having a different date when it kicks in does not help either...
suzyohas left
intosiDST: collectively tricking your employers into accepting it's okay to start and leave an hour earlier.
suzyohas joined
Lancehas joined
Ge0rGon a slightly related note, I'd really love board meetings to be one hour earlier.
Alexhas left
Viniloxhas joined
nicolas.veritehas joined
nicolas.veritehas left
suzyohas joined
jubalhhas joined
suzyohas joined
bjchas joined
bjchas joined
jerehas left
jerehas joined
SamWhitedhas left
kalkinhas left
intosihas left
vurpohas left
vurpohas joined
SamWhitedOh typical, and the IANA contact apparently doesn't work for Cisco anymore so the only email listed is broken.
nicolas.veritehas joined
kalkinhas joined
SamWhitedFound a personal email; let's try that.
nicolas.veritehas left
SamWhitedOh no, matt already forwarded it. Convenient.
intosihas joined
vurpohas left
vurpohas joined
Alexhas joined
ralphmhas left
vurpohas left
vurpohas joined
Holgerhas left
intosihas left
Yagizahas left
Guushas left
blipphas left
blipphas joined
goffihas left
suzyohas left
mimi89999has left
ilmaisinhas joined
intosihas joined
mimi89999has left
Martinhas left
SamWhitedhas left
mimi89999has left
Guushas left
Steve Killehas left
Steve Killehas left
Steve Killehas joined
Guushas left
vurpohas left
vurpohas joined
jubalhhas left
jubalhhas joined
nycohas joined
SouLhas left
Zashhas left
rionhas left
Zashhas joined
Zashhas left
Zashhas left
Alexhas left
Alexhas joined
Valerianhas left
Alexhas left
Alexhas left
Alexhas left
SamWhitedhas left
Alexhas left
Valerianhas joined
intosihas left
Guushas left
Alexhas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
Valerianhas left
Guushas left
efrithas joined
Alexhas left
Valerianhas joined
goffihas joined
Guushas left
alhitihas joined
alhitihas left
Lancehas left
kalkinhas left
Alexhas left
Laurahas joined
Laurahas left
Neustradamushas left
danielhas left
Alexhas joined
nycohas joined
rionhas joined
Alexhas left
jonaswhas left
Ge0rGhas left
nicolas.veritehas joined
jubalhhas left
nicolas.veritehas left
Alexhas joined
suzyohas joined
Alexhas left
nicolas.veritehas joined
alhitihas joined
jubalhhas joined
alhitihas left
kaboomhas left
Manchohas left
kaboomhas left
Guushas left
suzyohas left
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
kalkinhas left
Valerianhas joined
nicolas.veritehas left
nycohas joined
uchas left
uchas joined
Ge0rGhas left
Valerianhas left
kaboomhas left
nycohas joined
jonaswhas left
nicolas.veritehas joined
Valerianhas joined
moparisthebesthas left
nicolas.veritehas left
rionhas left
rionhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
efrithttps://xkcd.com/1810/
suzyohas joined
moparisthebesthas joined
nycohas joined
rionhas left
rionhas joined
rionhas left
rionhas joined
kaboomhas left
SamWhitedhas left
kaboomhas left
lskdjfhas joined
lskdjfhas left
kaboomhas left
nycohas joined
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
nicolas.veritehas joined
Valerianhas left
kaboomhas left
kaboomhas left
kaboomhas left
kaboomhas left
rionhas left
SouLhas left
kaboomhas left
kaboomhas left
efrithas joined
nicolas.veritehas left
Manchohas left
kaboomhas left
Alexhas left
kaboomhas left
kaboomhas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
sezuanhas left
kaboomhas left
Alexhas joined
Alexhas left
suzyohas left
Manchohas left
nicolas.veritehas joined
intosihas joined
danielhas left
danielhas joined
sezuanhas left
kaboomhas left
SouLhas left
kaboomhas left
SouLhas left
kaboomhas left
kaboomhas left
waqashas left
kaboomhas left
jubalhhas left
Guushas left
Alexhas left
vurpohas left
vurpohas joined
winfriedhas left
jerehas left
Lancehas joined
sonnyhas joined
sonnyhas joined
Alexhas joined
nycohas joined
Tobiashas joined
Lancehas left
efrithas joined
nicolas.veritehas left
sezuanhas left
nycohas joined
nicolas.veritehas joined
Alexhas left
intosihas left
nicolas.veritehas left
kaboomhas left
kaboomhas left
vurpohas left
vurpohas joined
vurpohas left
vurpohas joined
vurpohas left
efrithas joined
nycohas joined
vurpohas joined
Manchohas left
moparisthebesthas joined
Manchohas left
nicolas.veritehas joined
sonnyhas left
sonnyhas joined
moparisthebestSamWhited: sorry, I can't help but feel this is all my fault :-)
XSF Discussion - 2017-03-13