Re: [Standards] Bookmarks and autojoin issues
Hi, The problem is there are no rules what goes into which profile. If i add a bookmark as a desktop client, i don't know if it should go into the mobile profile or not. And btw we try to abstract bookmarks away from the user, so managing profiles of bookmarks for different devices is exactly not the direction i want to go. So either this can be determined automatically without user input (i doubt it) or a simple local autojoin list where the user simply has to manually join bookmarks is better in my opinion. Regards Philipp Am So., 24. Mai 2020 um 01:17 Uhr schrieb Maxime Buquet : > On 2020/05/24, Mathieu Pasquet wrote: > > Greetings, > > > > I want to raise an issue that appears with bookmarks in their current > > form in the multi-client scenario. It appears as long as we have more > > than one client, and gets worse for every added client and MUC bookmark. > > > > XEP-0048 and XEP-0402 both re-use the element, which has > > an autojoin flag. In a single-client scenario this is fine because that > > represents what the user wants in terms of joined rooms. In a > > multi-client scenario however, that quickly changes as you probably do > > not want the same view everywhere. > > I agree. > > > The use cases I have in mind are a bit extreme (e.g. people with > 100 > > MUCs in their autojoined bookmarks), which are unusable on mobile, for > > example, where screen space is limited and you probably want to limit > > yourself to the "important" ones. Or when joining big IRC channels with > > more than 1000 users, you also do not want that on mobile as that much > > activity is never good for battery life, however optimized the client > > might be. Even for smaller cases, such as 20-30 rooms, this can be a > > limiting factor. > > > > Bookmarks in themselves only represent MUCs we want to keep in memory, > > and that is fine. However tying the "autojoin" attribute in there means > > we are now syncing client state, and that is not often desirable, for > > the reasons stated above (different constraints, different platforms, > > different attention spans). > > > > The following is probably over-engineered for a nerdy edge case, but one > > viable solution would be the ability to manage sets of client "profiles" > > which would hold client state independently from bookmarks. This could > > be stored in PEP as well, and could be a list of pubsub URIs to the > > stored bookmarks. Removing a bookmark would automatically remove the > > autojoin in all profiles that link to it. > > I'm thinking that even if some clients don't want to implement support > for multiple profiles, they could "just" implement support for a > single/default profile, still allowing advanced clients to use different > ones. > > This would allow for the bookmark list would to be a bookmark list and > not a syncing mechanism. > > That list could be used in various cases where completion/suggestions > are helpful. > > -- > Maxime “pep” Buquet > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Mathieu Pasquet wrote: > Greetings, > > I want to raise an issue that appears with bookmarks in their current > form in the multi-client scenario. It appears as long as we have more > than one client, and gets worse for every added client and MUC bookmark. > > XEP-0048 and XEP-0402 both re-use the element, which has > an autojoin flag. In a single-client scenario this is fine because that > represents what the user wants in terms of joined rooms. In a > multi-client scenario however, that quickly changes as you probably do > not want the same view everywhere. I agree. > The use cases I have in mind are a bit extreme (e.g. people with > 100 > MUCs in their autojoined bookmarks), which are unusable on mobile, for > example, where screen space is limited and you probably want to limit > yourself to the "important" ones. Or when joining big IRC channels with > more than 1000 users, you also do not want that on mobile as that much > activity is never good for battery life, however optimized the client > might be. Even for smaller cases, such as 20-30 rooms, this can be a > limiting factor. > > Bookmarks in themselves only represent MUCs we want to keep in memory, > and that is fine. However tying the "autojoin" attribute in there means > we are now syncing client state, and that is not often desirable, for > the reasons stated above (different constraints, different platforms, > different attention spans). > > The following is probably over-engineered for a nerdy edge case, but one > viable solution would be the ability to manage sets of client "profiles" > which would hold client state independently from bookmarks. This could > be stored in PEP as well, and could be a list of pubsub URIs to the > stored bookmarks. Removing a bookmark would automatically remove the > autojoin in all profiles that link to it. I'm thinking that even if some clients don't want to implement support for multiple profiles, they could "just" implement support for a single/default profile, still allowing advanced clients to use different ones. This would allow for the bookmark list would to be a bookmark list and not a syncing mechanism. That list could be used in various cases where completion/suggestions are helpful. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
Another perspective for profiles is work/life balance. Work/life MUCs or anything else fitting this concept. Particularly in Psi I've already added some options allowing to ignore some autojoining mucs for example at work or local-only (not stored on a server) bookmarks. Best Regards, Sergey вс, 24 мая 2020 г. в 01:56, Sam Whited : > On Sat, May 23, 2020, at 18:41, Mathieu Pasquet wrote: > > In a multi-client scenario however, that quickly changes as you > > probably do not want the same view everywhere. > > I disagree, I always want exactly the same view everywhere. Otherwise I > inevitably leave my desk and then try to look up something on my phone > that someone mentioned earlier and can't find it because I'm not > actually joined to that room. I do not know if my view on this is more > prevalent than people who want their phone joined to different rooms or > not, but I definitely want to dispute the "probably do not want the same > view" in the previous message. > > —Sam > > -- > Sam Whited > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On Sat, May 23, 2020, at 18:41, Mathieu Pasquet wrote: > In a multi-client scenario however, that quickly changes as you > probably do not want the same view everywhere. I disagree, I always want exactly the same view everywhere. Otherwise I inevitably leave my desk and then try to look up something on my phone that someone mentioned earlier and can't find it because I'm not actually joined to that room. I do not know if my view on this is more prevalent than people who want their phone joined to different rooms or not, but I definitely want to dispute the "probably do not want the same view" in the previous message. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Bookmarks and autojoin issues
Greetings, I want to raise an issue that appears with bookmarks in their current form in the multi-client scenario. It appears as long as we have more than one client, and gets worse for every added client and MUC bookmark. XEP-0048 and XEP-0402 both re-use the element, which has an autojoin flag. In a single-client scenario this is fine because that represents what the user wants in terms of joined rooms. In a multi-client scenario however, that quickly changes as you probably do not want the same view everywhere. The use cases I have in mind are a bit extreme (e.g. people with > 100 MUCs in their autojoined bookmarks), which are unusable on mobile, for example, where screen space is limited and you probably want to limit yourself to the "important" ones. Or when joining big IRC channels with more than 1000 users, you also do not want that on mobile as that much activity is never good for battery life, however optimized the client might be. Even for smaller cases, such as 20-30 rooms, this can be a limiting factor. Bookmarks in themselves only represent MUCs we want to keep in memory, and that is fine. However tying the "autojoin" attribute in there means we are now syncing client state, and that is not often desirable, for the reasons stated above (different constraints, different platforms, different attention spans). The following is probably over-engineered for a nerdy edge case, but one viable solution would be the ability to manage sets of client "profiles" which would hold client state independently from bookmarks. This could be stored in PEP as well, and could be a list of pubsub URIs to the stored bookmarks. Removing a bookmark would automatically remove the autojoin in all profiles that link to it. Mathieu signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On 23.05.2020 20:08, Georg Lukas wrote: [snip] This is a very short and very slippery slope. I'm sure that you are aware of the coordinated attacks on centralized social networks where trolls mass-report accounts that they disagree with. It's okay to block a certain sender JID on your own account without any evidence, but I'm really hesitant to create an instrument that has even a small chance of feeding forged evidence to server administrators. Running a public server is hard enough already without having to investigate such anti-abuse abuse, and I'm pretty sure that the "paid xmpp DDoS" sellers will quickly adopt if you give them such a stick to wield. I concur, although I will point out that attacks on centralized social networks do not even need to falsify the contents of the incriminated message. They only use mass reporting together with a bogus abuse subject, and that is enough in itself to trigger an automated removal (or suspension) of the reported content. Here our intent is not to flag what is or what is not acceptable for private exchanges, but rather to get evidence linked to the report, to determine the best course of action (assuming the abuser is on another server, for the most part). Having one or several stanzas attached to the report, with the guarantee that they are unaltered, is in my opinion one of the best way to gather that information. Mathieu ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Sat, May 23, 2020, at 14:08, Georg Lukas wrote: > I'm not sure when you would come into a situation where you don't > report a spam message in a timely manner but let it sit there for > multiple weeks. I'm not sure when we'd hit that situation either, but that's not going to make it any less weird when it happens. > I'm sure that you are aware of the coordinated attacks on > centralized social networks where trolls mass-report accounts that > they disagree with. I am aware of them, and I do think we should try to avoid putting burden on server operators as much as possible, but also I suspect you have to check out reports no matter what. Although I would be more worried that server operators would just trust what was in the payload if we did it this way. Mass fake reports could be a problem with sending stanza IDs as well, especially if the attackers just use a stanza that has expired from the archive. Either way the operator probably has to do something to verify that the message was spam and/or actually existed or that the user continues to send spam. How spam reports are handled will always be very service specific too. Servers could do anything from verifying it against the MAM archive anyways if the specific account has a permanent archive enabled, or they could do something more clever like generate IDs based on a signature of the message so that they can verify that the forwarded message hasn't been modified (this would be overkill to include in the XEP, but it has no compatibility requirements so individual servers and services could do something like this if they wanted and no one else would know the difference). Anyways, just spitballing, I suspect we could find a couple of good ways for servers to verify messages and just include a mention of it in the security considerations if we went with a "forward the message back" approach. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
* Sam Whited [2020-05-23 15:40]: > On Sat, May 23, 2020, at 06:24, Mathieu Pasquet wrote: > > Sorry for the necromancer update, but would it not make sense to allow > > stanza-id elements as children to the and elements? Yeah, that's actually what also came to my mind as an easy and straight-forward way to significantly improve the usefulness of 0377 for server admins. > I think that including a stanza-id is probably "good enough", but I'm > also a little worried about the fact that you would then only be able to > report recent messages, which feels like it would be unexpected and > could make training a spam filter less easy. I'm not sure when you would come into a situation where you don't report a spam message in a timely manner but let it sit there for multiple weeks. > I'm now wondering if it makes sense to forward the entire original > message and just trust that it's not all that easy to abuse [...] This is a very short and very slippery slope. I'm sure that you are aware of the coordinated attacks on centralized social networks where trolls mass-report accounts that they disagree with. It's okay to block a certain sender JID on your own account without any evidence, but I'm really hesitant to create an instrument that has even a small chance of feeding forged evidence to server administrators. Running a public server is hard enough already without having to investigate such anti-abuse abuse, and I'm pretty sure that the "paid xmpp DDoS" sellers will quickly adopt if you give them such a stick to wield. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On Sat, May 23, 2020, at 06:24, Mathieu Pasquet wrote: > Sorry for the necromancer update, but would it not make sense to allow > stanza-id elements as children to the and elements? Georg and I were talking about this a few days ago and I would definitely like to add some way to report individual messages. I think that including a stanza-id is probably "good enough", but I'm also a little worried about the fact that you would then only be able to report recent messages, which feels like it would be unexpected and could make training a spam filter less easy. I'm now wondering if it makes sense to forward the entire original message and just trust that it's not all that easy to abuse because a single report probably won't result in a user being banned and even if a potential attacker creates dozens of accounts that all report the same user a quick look at the messaging stats (or whatever metrics server administrators keep to track spammers) will likely show that they're not a spammer. —Sam -- Sam Whited -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Server status pages
On 23.05.2020 11:38, Matthew Wild wrote: On Sat, 23 May 2020, 10:51 Maxime Buquet, wrote: All those who expressed feelings against adding this to 157 at the time you sent this didn't mention why. I personally don't see much issue with it, so I just PR'd against it to add that registry entry. Just want to add a couple of things that have come up in discussions since starting this thread: 1) Someone (sorry, don't remember who) had the idea of including this in DNS. Advantages: - the client doesn't need to discover and cache the value after login, it can discover it on-demand whenever it has connection issues - the admin is able to add/update the value while the service is down Disadvantages: - Not all clients may be in a position to query TXT records (web clients, may require additional dependency in native clients) - Not necessarily secure without DNSSEC - Additional work for people who want to delegate a domain for XMPP hosting by a third party Putting this part into perspective, while I like the DNS solution, that’s yet another "out of band " bit to setup, and I don’t see a huge benefit compared to caching regularly that bit of info from the disco. (at jabberfr we have one ouf our "big" XMPP domains managed by someone else, and it can take weeks to update DNS records… It’s not very practical.) The only functional downside of re-using 0157 for that purpose would be if the server is down before the very first connection of the client, then it has no way of knowing, but is it a case we want to optimize? Mathieu ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Server status pages
On Sat, 23 May 2020, 10:51 Maxime Buquet, wrote: > All those who expressed feelings against adding this to 157 at the time > you sent this didn't mention why. > > I personally don't see much issue with it, so I just PR'd against it to > add that registry entry. Just want to add a couple of things that have come up in discussions since starting this thread: 1) Someone (sorry, don't remember who) had the idea of including this in DNS. Advantages: - the client doesn't need to discover and cache the value after login, it can discover it on-demand whenever it has connection issues - the admin is able to add/update the value while the service is down Disadvantages: - Not all clients may be in a position to query TXT records (web clients, may require additional dependency in native clients) - Not necessarily secure without DNSSEC - Additional work for people who want to delegate a domain for XMPP hosting by a third party 2) It would be nice if we could optionally provide something machine-readable that clients can natively display rather than redirecting to a web browser. That's all. I'm fine with the 157 proposal if it's the easiest path. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On 5/23/20 12:24 PM, Mathieu Pasquet wrote: > > On 12.09.2017 12:45, Georg Lukas wrote: >> * Sam Whited [2017-09-12 01:52]: >>> I had assumed that the server would be storing things and we didn't need >>> to send it back, but maybe that's not always the case. This does seem >>> like the kind of thing we might need to store or send back somehow. >> >> Yeah, this is going to be challenging. I'd really love to get the >> message content and not just the sender JID on my spam reports. That >> would require either MAM or some ring buffer of messages, which is all >> not-so-neat, or the client to reflect the offensive message inside the >> report, which is also challenging on it's own, and adds the security >> problems Kim outlined. >> >> A trade-off solution might be to make MAM an (optional) prerequisite. A >> client supporting MAM could add the of an offensive message >> into the report, giving the server a sufficiently large time window to >> obtain the message from its MAM store. >> >> If either entity lacks MAM support, we fall back to blocking the JID >> without further knowledge of the actual message content. > > Sorry for the necromancer update, but would it not make sense to allow > stanza-id elements as children to the and elements? +1 It never can hurt to provide additional information, especially if it is optional. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)
On 12.09.2017 12:45, Georg Lukas wrote: * Sam Whited [2017-09-12 01:52]: I had assumed that the server would be storing things and we didn't need to send it back, but maybe that's not always the case. This does seem like the kind of thing we might need to store or send back somehow. Yeah, this is going to be challenging. I'd really love to get the message content and not just the sender JID on my spam reports. That would require either MAM or some ring buffer of messages, which is all not-so-neat, or the client to reflect the offensive message inside the report, which is also challenging on it's own, and adds the security problems Kim outlined. A trade-off solution might be to make MAM an (optional) prerequisite. A client supporting MAM could add the of an offensive message into the report, giving the server a sufficiently large time window to obtain the message from its MAM store. If either entity lacks MAM support, we fall back to blocking the JID without further knowledge of the actual message content. Georg Sorry for the necromancer update, but would it not make sense to allow stanza-id elements as children to the and elements? That would make for a pretty simple change, keeping existing implementations working, but would also allow updated server implementations to extract the message contents from the local MAM archive (if enabled). If there is no archive, then the situation is the same as what it currently is. Mathieu ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Server status pages
On 2018/12/03, Matthew Wild wrote: > Hi all, > > I'd like to allow servers to advertise status pages to their users. > See for example https://statut.jabberfr.org/ > > This information could be cached by clients, and linked to in case of > problems connecting, for example. > > The question is where and how to advertise it. Someone suggested it > might fit into XEP-0157, as if you squint hard enough, it is a > communication channel about the service. The link could also be a URL > to a Twitter, Mastodon feed, or whatever. > > This is one possibility, there are others. Anyone have thoughts to contribute? All those who expressed feelings against adding this to 157 at the time you sent this didn't mention why. I personally don't see much issue with it, so I just PR'd against it to add that registry entry. https://github.com/xsf/xeps/pull/949 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
