Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
Todd,
when you see this here and have a minute, would you mind having a look at monoidal category to see if you can remove the query-box discussion there and maybe replace it by some crisp statement?
Thanks!
I’ll get to it when I can, probably sometime later today.
I have removed the first query box and inserted a proof of one of Max Kelly’s lemmas. I’ll get to the other in a bit, the one that says .
That’s great, thank you, Todd!
I’ll have a look as soon as the Lab wakes up again…
Yes, it’s slow, isn’t it? But I managed to stick in the other lemma as well. I’ll finish up by describing what Joyal and Street do (will have to be later today).
Thanks, Todd.
Looking at what you have now, I wonder if the section Definition – Other coherence conditions should not be moved to the Properties-section, where already a stub section “Properties - Coherence” is waiting with a link to coherence theorem for monoidal categories, which in turn linke to Mac Lane’s proof of the coherence theorem for monoidal categories.
Somehow all this would deserve to be put coherently in one place. What do you think? Do you have any plans with this material?
all this would deserve to be put coherently in one place
Heh. Good one.
Anyway, yes, I agree with you. I have to be doing other things now, but if you would like to rearrange the material, please go right ahead. I was mainly trying to take care of Adam’s queries (that have now been removed).
Looking at the two nLab articles you linked to – they could use some more work. “Mac Lane’s proof” is really long and might look scarier to the reader than it actually is. Hopefully I’ll get some time soon to give them a crack.
Okay, if I may, might play with rearranging the material in some way a little later. Thanks.
Added to the References-section at monoidal category right at the beginning a pointer to the pretty comprehensive set of lecture notes:
some super cryptic Anonymous added the following reference which I have rolled back
Anonymous put back again this reference which I have again reverted. The two edits come from Bell Canada in Montreal but they are different IP which means we can’t use IP blocking.
Should we put a note in monoidal category#references telling him to desist and directing him to this thread in the nForum?
Thanks for dealing with this Rod. That might be a reasonable strategy; put it in a query box probably.
He did it a gain so I put in a query box.
Edit. I checked wikipedia monoidal category and he did the same thing there which I also removed.
Looks like he also did the same on August 31 at coherence theorem for monoidal categories and Mac Lane’s proof of the coherence theorem for monoidal categories. I’ve removed the links.
There is something strange now in Mac Lane’s proof of the coherence theorem for monoidal categories. There are many new general sections (apparently not belonging in this entry, but rather in monoidal category) even before the Contents, and the first actual section (“Introduction and statement”) is labeled section 18.
There was a ’>’ right at the start that was mucking things up! I removed it and it looks much better!
Great, thanks!
He back, reinserting his reference into every thing its been removed from. I haven’t reverted them yet.
Do we need to contact Bell Canada and see if they can get him to stop or just block all the Bell Canada Montreal IP addresses?
Maybe we should just precede his references with a query box that says “1337777.OOO is a deranged crackpot that insists on including this reference and every time we remove it he adds it back “
Bah. Can we tell whether anyone legitimate is using those IP addresses?
Mike:
Do you mean, any legitimate nLab user?
At any rate, trying to block this user by IP address is unlikely to be fruitful; I note that their latest re-addition is from yet another IP address, 70.29.194.190. Blocking Bell Canada’s entire IP block (or at least their entire Montreal block) seems quite the sledgehammer.
Is the Instiki config/spam_patterns.txt file used by the nLab wiki? If so, adding things like:
1337777\.OOO
Maclane pentagon is some recursive square
github\.com/1337777
to that list might be another way forward. To get around that, the user would need to change the name they’re using, change the name of their article, and change the name of their GitHub account (or create a new one).
(Also, this user appears to have started ’contributing’ to the Coq-club list: https://sympa.inria.fr/sympa/arc/coq-club/2017-08/msg00048.html.)
Gah, just realised the user also has a GitLab account, so
gitlab\.com/1337777
would be another thing to add to that list.
20: Good idea, I’ve just done that .
Ok I’ve removed 1337777”s references from monoidal category, coherence theorem for monoidal categories, and Mac Lane’s proof of the coherence theorem for monoidal categories.
and also the query box
+-- {: .query}
__1337777.OOO__. Stop trying to insert your reference until you have explained and discussed it in
the [nForum: monoidal-category](https://nforum.ncatlab.org/discussion/4226/monoidal-category). It is annoying to keep having to remove it.
=--
Let’s see if the blocking works and see if 1337777 is determined enough to work around it.
EDIT: I’ve also removed his reference from Wikipedia Monoidal_category, Coherence_theorem, and Coherence_condition.
Thanks everyone!
He’s back on all three pages. DId the spam list changes not propagate to the running code?
He bypassed the spam filter by subtly modifying the offending keywords (underscores, extra slashes, etc.). I think maybe I should just block the keyword 1337777 for a while.
Could the ’Block or report user’ at https://github.com/1337777 be used? There’s an option “Contact Support about this user’s behavior”.
It seems unlikely that there will ever be a legitimate use of 1337777. Reporting him to github seems like a good plan too.
Hm, looking at the user’s change to the ’monoidal category’ page, the spam filter should have still blocked the edit via the patterns for “Maclane pentagon is some recursive square” and “1337777.OOO”. Did the restart of Instiki, so that the new patterns get included, maybe not complete properly?
I just removed a new insertion of the link. The second part of that link makes more sense than the first part, which is just two diagrams, but is also very difficult to read and does not fit in that part of the reference list.
29: if you look at the source,
1337777\.OOO , _Maclane pentagon is some recursive_ _square ...
The backslash makes it a different string than 1337777.OOO, and similarly the _ _ “escapes” the second string. Anyway, let’s see how he gets around this…
Ah, good point, I’d not looked at the page source ….
Yes, will indeed be interested to see if this user is able to work around your latest change. :-)
He’s certainly persistent!
Indeed, rudely so.
The latest readdition gets around the spam filter by using HTML character entities:
1337777.OOO
I’ve taken a look at the Instiki source, and the patterns used in spam_patterns.txt are actually Ruby regexes. So maybe an entry like this could be used:
(?:1|&#\d{2,4};|&#x\d{2,4};)(?:3|&#\d{2,4};|&#x\d{2,4};)(?:3|&#\d{2,4};|&#x\d{2,4};)(?:7|&#\d{2,4};|&#x\d{2,4};)(?:7|&#\d{2,4};|&#x\d{2,4};)(?:7|&#\d{2,4};|&#x\d{2,4};)(?:7|&#\d{2,4};|&#x\d{2,4};)
Also note that the user seems to be following this thread.
How does wikipedia deal with people like this?
@Mike:
The wiki software used by Wikipedia, MediaWiki, has functionality to deal with this sort of situation. Instiki doesn’t seem to have functionality to e.g. allow the site admin to lock a page against edits until further notice.
I’m surprised if simply locking a few pages temporarily is usually sufficient. But it would certainly be a nice option to have.
Reporting the user to his ISP seems like a reasonable decision to me.
Instiki doesn’t seem to have functionality to e.g. allow the site admin to lock a page against edits until further notice.
It is pretty easy to manually hardcode this though, as I’ve just done.
Oh, you’re right, of course - temporarily locking pages is not necessarily going to be sufficient. It’s a game of Chicken; who’s going to give up first? Still, MediaWiki has finer-grained functionality available:
MediaWiki offers flexibility in creating and defining user groups. For instance, it would be possible to create an arbitrary "ninja" group that can block users and delete pages, and whose edits are hidden by default in the recent changes log. It is also possible to set up a group of "autoconfirmed" users that one becomes a member of after making a certain number of edits and waiting a certain number of days. Some groups that are enabled by default are bureaucrats and sysops. Bureaucrats have power to change other users' rights. Sysops have power over page protection and deletion and the blocking of users from editing. MediaWiki's available controls on editing rights have been deemed sufficient for publishing and maintaining important documents such as a manual of standard operating procedures in a hospital.
Whereas Instiki seems to only provides access control at the ’web’ level, not the ’page’ level.
From experience, I don’t actually have much confidence in large ISPs actively addressing this sort of situation adequately, but I guess it’s worth a go at this point (as might be contacting GitHub and GitLab about this user as well).
@Adeel:
Nice!
1337777.OOO is back, adding links to at least
On it.
I have tightened the spam filter now. I will not say exactly how, as, as mentioned above, the user may be watching this thread. I have not committed the change anywhere, so there is nowhere to find it (unless one has access to the server).
I will now see if I can clear up in the database (update: actually will have to postpone until later; I will also attempt to strengthen the spam filter further, what I’ve done now will probably only stop the posts for a while).
Have now cleared up everything with
1337777.OOO
with the HTML character in the middle, including some older pages. There exist some historical ones (only in revision history I think) without the HTML character in the middle, I’ll try to remove those tomorrow.
I’ve also tightened the spam filter a little further.
Thanks very much for the alert, Rod!
The page Mac+Lane’s+proof+of+the+coherence+theorem+for+monoidal+categories still contains links of similar type at the bottom.
Thanks for raising this, deleted these revisions from September now, and blocked the IP address as well in nginx, because it has been used consistently.
I actually don’t know how the author managed to get those edits through; my attempts to reproduce the spam result in the spam filter blocking the edits correctly. It is possible that I misread the date to be from an earlier year than this year (i.e. it was just something that I forgot to clear up).
1 to 50 of 50