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

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

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

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

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

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,

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Tue, Sep 12, 2017, at 10:06, Evgeny Khramtsov wrote: > And say bye-bye to namespace delegation? Does namespace delegation only work on top level IQs (I guess it would have to unless you wanted to do some weird forward-lookahead type stuff)? I hadn't actually considered it because I didn't know

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 09:21:00 -0500 Sam Whited wrote: > Would not making it a dependency and merging it into the Blocking XEP > solve this for you as well? And say bye-bye to namespace delegation? At the moment we don't have any plans to add XEP-0377 functionality (largely

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Tue, Sep 12, 2017, at 09:16, Holger Weiß wrote: > But I still believe it's wrong to let one feature depend on another one > without a technical reason. Dependencies can lead to issues Would not making it a dependency and merging it into the Blocking XEP solve this for you as well? —Sam

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

* Matthew Wild [2017-09-12 12:35]: > On 12 September 2017 at 12:10, Guus der Kinderen > wrote: > > I'd much more prefer a solution where spam is reported (as a stand-alone > > action, not embedded in a block), with an implementation guideline that >

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12 September 2017 at 12:47, Guus der Kinderen wrote: > Not all blocking comes from SPAM reports. XEP-0191 isn't duplicated by > creating a SPAM report, as it also allows you to block entities for any > other reason (annoying automated messages, in-laws, etc). I

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12.09.2017 13:35, Matthew Wild wrote: > On 12 September 2017 at 12:10, Guus der Kinderen > wrote: >> I'd much more prefer a solution where spam is reported (as a stand-alone >> action, not embedded in a block), with an implementation guideline that >> reads

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Not all blocking comes from SPAM reports. XEP-0191 isn't duplicated by creating a SPAM report, as it also allows you to block entities for any other reason (annoying automated messages, in-laws, etc). As for delivery: at the very least, you can do the same as what the current XEP tells you to do:

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12 September 2017 at 12:10, Guus der Kinderen wrote: > I'd much more prefer a solution where spam is reported (as a stand-alone > action, not embedded in a block), with an implementation guideline that > reads something like "Upon receiving a report, the server

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 13:10:54 +0200 Guus der Kinderen wrote: > By not tying this XEP to Blocking, the XEP becomes even easier to > implement, but also more versatile. As a slightly embarrassing, but > truthful, illustration: if this XEP would not have been dependent on >

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Although I agree that not receiving messages from the reported entity is a good thing. I'm still not comfortable with embedding the spam-reporting in blocking functionality. I'd much more prefer a solution where spam is reported (as a stand-alone action, not embedded in a block), with an

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 12:11:45 +0200 Daniel Gultsch wrote: > By bundling it with blocking we 'force' a consistent UI among > clients. And on the other hand 'forces' server devs to put all functionality into a single module or building modules dependencies. In the case of clients

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

* Dave Cridland [2017-09-12 11:02]: > FWIW, I've never bothered blocking any spammers, because it looks like > they always use a throwaway address anyway. I think the push behind the Spam Reporting XEP is to allow the server admins who are not in the lucky position of getting

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

* 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

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 12:25:55 +0200 Jonas Wielicki wrote: > Nobody said that the element necessarily has the same namespace as > currently used by other XEP-0191 elements. So I can easily add elements such as inside a because why not? There is only SHOULD and also guys from

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Dienstag, 12. September 2017 12:11:45 CEST Daniel Gultsch wrote: > I have implemented the XEP in Conversations and find it very useful. > > I actually like the bundling with the blocking XEP for two reasons. > > 1) 'Reporting' a JID comes at a cost of not being able to receive > messages from

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Dienstag, 12. September 2017 12:59:48 CEST Evgeny Khramtsov wrote: > > That is the whole point of extensibility. > > No, as I see it, the point of extensibility is to add elements within > another namespaces instead of injecting elements into existing ones. Nobody said that the element

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

I have implemented the XEP in Conversations and find it very useful. I actually like the bundling with the blocking XEP for two reasons. 1) 'Reporting' a JID comes at a cost of not being able to receive messages from that JID again. Yes it is reversible and yes this doesn't protect us from

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 11:34:26 +0200 Jonas Wielicki wrote: > You are wrong, I think. RFC 6120, Section 11.4 Validation: The section says nothing about servers. And the receiving entity is a server in our case. > That is the whole point of extensibility. No, as I see it, the

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Dienstag, 12. September 2017 12:05:27 CEST Evgeny Khramtsov wrote: > Tue, 12 Sep 2017 10:02:26 +0100 > > Dave Cridland wrote: > > I don't think so. We're just adding an element, so it could be done > > with just a new disco feature, I think. > > Hum, am I missed something?

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 10:02:26 +0100 Dave Cridland wrote: > I don't think so. We're just adding an element, so it could be done > with just a new disco feature, I think. Hum, am I missed something? Strict xmpp entities could not allow elements not defined in schema, no?

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12 September 2017 at 09:35, Evgeny Khramtsov wrote: > Mon, 11 Sep 2017 18:14:38 -0500 > Sam Whited wrote: > >> That sounds good to me, I'll see if I can't prepare an update to do >> that. Since the blocking command is draft I'm not sure that it's >>

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 18:14:38 -0500 Sam Whited wrote: > That sounds good to me, I'll see if I can't prepare an update to do > that. Since the blocking command is draft I'm not sure that it's > possible. There is a problem, because we need to bump XEP-0191's namespace (there is

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Montag, 11. September 2017 18:51:35 CEST Sam Whited wrote: > On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote: > > The SPAM payload itself is of interest for further analysis, so a way to > > get it would be nice. But we don't want to make it easy to lie and > > submit something and claim it

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On 12.09.2017 00:39, Kim Alvefur wrote: > On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote: >> On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: >>> XEP-0377 (Spam Reporting) has been Deferred because of inactivity. >> >> Hi all. Spam reporting was just (correctly) deferred. Several

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote: > The SPAM payload itself is of interest for further analysis, so a way to > get it would be nice. But we don't want to make it easy to lie and > submit something and claim it came from an innocent. Perhaps a message > id, that could be corelated

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 17:51, Evgeny Khramtsov wrote: > Well, actually I'm open to find a compromise. If the author insists on > wrapping it into element and says that this is a "blocking > reason", then I'm fine with defining this in XEP-0191. This should not > be a problem, right? Because

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 17:39, Evgeny Khramtsov wrote: > Deprecating something doesn't magically solve the problem and force > operators/users to update software (remember vcard avatars or private > storage, though, they are not formally deprecated, but deprecation will > not change anything). So

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Tue, 12 Sep 2017 00:05:07 +0200 Philipp Hörist wrote: > It just makes me sad, that not even about something basic and easy > like reporting a jid for spam, we can find to an agreement. Well, actually I'm open to find a compromise. If the author insists on wrapping it into

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 22:28:29 + Sam Whited wrote: > XEP-0016 is deprecated so I am not interested in making this more > complicated to support it. Deprecating something doesn't magically solve the problem and force operators/users to update software (remember vcard avatars

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Hi, On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote: > On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: > > XEP-0377 (Spam Reporting) has been Deferred because of inactivity. > > Hi all. Spam reporting was just (correctly) deferred. Several servers > have implemented it, but only

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On September 11, 2017 4:44:27 PM CDT, Evgeny Khramtsov wrote: >So, probably? Or are you absolutely sure? No, but this isn't designed to be a one size fits all solution to every problem under the sun, it's supposed to provide a simple, easy to implement solution for saying

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

No not for me, in fact having one spam XEP on its own, and a second one with a report function in blocking command, makes implementation for clients more complicated. (not much although, we talking here about checking for one more feature) Roundtrips is not a good argument for me either, because

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 23:52:46 +0200 Philipp Hörist wrote: > Afterwards we could do the addition to blocking command for the report > function, as long as there is discovery for this additional feature to > blocking command I'm curious what problem does this solve? Is there a

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Hi, As this is about SPAM we should aim for something very simple that everyone will implement. I think the XEP should be standalone, not tied to anything else at first. So Server developers can implement it without having to implement anything else. Afterwards we could do the addition to

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 16:32:23 -0500 Sam Whited wrote: > but if it is a spam report you probably always want it to result in a > block. So, probably? Or are you absolutely sure? Another question is what if the server doesn't have XEP-0191 module running, but, instead, have

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Blocking Reason and Spam Reporting 2.0 could happily coexist. :-) On 11 Sep 2017 23:32, "Sam Whited" wrote: > On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote: > > Let me answer. Because he thinks that those two actions should be > > always performed together. But in

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote: > Let me answer. Because he thinks that those two actions should be > always performed together. But in this case why do we need to have a > spam reporting mechanism? Let's assume that the blocked person is > always a spammer. Maybe this

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 23:07:57 +0200 Holger Weiß wrote: > I think it's obvious that you're not responding to the actual question > here, and I wonder why :-) Let me answer. Because he thinks that those two actions should be always performed together. But in this case why

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 16:08, Holger Weiß wrote: > Your assumption might be right or wrong. Using a separate query copes > with both cases. It also means the block and the spam report are no longer correlated and that there are more round trips with the server. Both of these don't seem

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

* Sam Whited [2017-09-11 15:32]: > I don't see why you'd want to report spam without also blocking the > sender personally. Your assumption might be right or wrong. Using a separate query copes with both cases. Holger ___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

* Sam Whited [2017-09-11 15:54]: > On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote: > > What is the problem with this??? The software should be modular and, if > > possible, there should be as less dependencies between modules as > > possible. > > I agree with this.

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 15:54:33 -0500 Sam Whited wrote: > On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote: > > What if we decide to report SPAM to a separate entities? > > That is out of the scope of this spec; that's more complicated, and is > not something that is

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote: > What if we decide to report SPAM to a separate entities? That is out of the scope of this spec; that's more complicated, and is not something that is allowed by this specification. > Really, we're now creating problems out of nothing. I

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

I'm not arguing that the XEP should define anything but the payload (and how entities do the initial reporting to their domain). Although there's no harm in blocking the sender of the spam that you reported, tying the two XEPs together implies that there are no other ways to prevent the spam

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 15:24:13 -0500 Sam Whited wrote: > In retrospect this flexibility feels poor to me; let's just have one > way to do things (which should be an extension of the blocking > command, IMO). What if we decide to report SPAM to a separate entities? Really, we're

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 22:21:17 +0200 Guus der Kinderen wrote: > spam can be reported to any entity that advertises support, > and could be inlined with Block if/when desired. So a server should support both methods? This is even worse.

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote: > I'm not sure if the "reporting" bit should automatically go hand in hand > with "blocking" specifically. There might be value in defining an entity > that simply just receives spam reports. Obviously, end-users generally > report spam

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

I'm not sure if the "reporting" bit should automatically go hand in hand with "blocking" specifically. There might be value in defining an entity that simply just receives spam reports. Obviously, end-users generally report spam because they want it to stop, but the goal of reporting could be

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote: > The integration with block is an optional part of the XEP, isn't it? I'm > reading it as: spam can be reported to any entity that advertises > support, > and could be inlined with Block if/when desired. Right now the only mechanism for

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 14:56, Evgeny Khramtsov wrote: > I actually reported the issue here: > https://mail.jabber.org/pipermail/standards/2017-January/031883.html > > TL;DR: I don't like the inclusion of element inside > element and, thus, will not implement it in such form. There should be >

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

The integration with block is an optional part of the XEP, isn't it? I'm reading it as: spam can be reported to any entity that advertises support, and could be inlined with Block if/when desired. On 11 September 2017 at 21:56, Evgeny Khramtsov wrote: > Mon, 11 Sep 2017

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

Mon, 11 Sep 2017 12:32:09 -0500 Sam Whited wrote: > Is there anything missing you think a spam reporting XEP must do? Was > your implementation experience (clients and servers) smooth? Did you > find any part of using it especially painful? How are you using it and > is the

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote: > XEP-0377 (Spam Reporting) has been Deferred because of inactivity. Hi all. Spam reporting was just (correctly) deferred. Several servers have implemented it, but only a handful of operators and client developers, as far as I can tell so I