- From: Christopher Allan Webber <cwebber@dustycloud.org>
- Date: Sun, 12 Apr 2015 18:28:20 -0500
- To: Evan Prodromou <evan@e14n.com>
- Cc: public-socialweb@w3.org
Christopher Allan Webber writes: > Christopher Allan Webber writes: > >> Evan Prodromou writes: >> >>>> 2. not all of us are sysadmins - I can set up a VPS, but being able to >>>> set one up securely is a profession all on its own. >>> Users can have hosting options; it doesn't have to be one or the other. >>> There are trade-offs. >>>> 3. lack of filtering tools - no ability to reduce line noise from >>>> people spamming. The service may as well actually be offline if >>>> you have to sift through large volumes of putrid hate speech before >>>> you can read anything from your friends and loved ones >>> There's no reason that the social service the user uses can't >>> incorporate filtering tools. For self-hosting people, they can use a >>> third-party spam filter. Akismet is one that works for blog comments in >>> this same topology; E14N runs one called spamicity.info for pump.io and >>> GNU Social users. >>> >>> That said, fine-grained tools don't exist now for pump.io or GNU social. >>> I think that having the option to use them is pretty important! >> >> So this came up in my talk at LibrePlanet, someone asked about this in >> the Q&A section, and there was some hallway talk afterwards. Previously >> I think this would happen only at a layer outside of the protocol, but >> others pointed out that the very tooling we're building now could help >> with anti-abuse, probably without adjustments to anything other than >> adding new vocabulary and specifying its side effects. For instance, >> you could federate information about known abusive users so you can help >> mitigate harassment between servers. >> >> I'm not sure whether or not it belongs in the core vocabulary but if >> well thought through I think I would like it. The main thing is that >> maybe it will be hard to get the implementation right; maybe it should >> be implemented as an extension for the vocabulary as we test it and then >> get it involved mainline. >> >> But Jessica Tallon has pointed out, even outside of the anti-harassment >> concerns, we probably want the technical primitives for this anyhow. >> Consider that multiple users probably should have permission to edit the >> same collection; we need some way to have access control for such a >> thing assuming we want to support such a feature. Adding verbs for >> block/mute on top of this are pretty reasonable, and not hard to picture >> as in terms of implementation. Perhaps we should have all of those in >> the core vocabulary? >> >> I know we don't have any user stories for this but I wish we had one. >> Maybe it would be nice to try to think one through? (I don't think I >> should be the one to submit it, but I'd like to get help on it; it might >> be helpful to get a user story from someone <way to say "who's not a >> white dude and is more at risk here">?) >> >> - Chris > > One other route for this is to do client-side filtering using machine > learning and bayesian filters that help users sort out what stuff they > want to read and what type of stuff seems like abuse. > > Here's some indications that this might be feasible: > > - Anti-troll machine learning > http://www.technologyreview.com/view/536621/how-a-troll-spotting-algorithm-learned-its-anti-antisocial-trade/ > and associated paper > http://arxiv.org/abs/1504.00680 > http://arxiv.org/pdf/1504.00680v1.pdf > - Collaborative filtering with privacy > http://www.cs.berkeley.edu/~jfc/%27mender/IEEESP02.pdf > > Probably worth researching... > - Chris One more: http://dl.acm.org/citation.cfm?id=2459900
Received on Sunday, 12 April 2015 23:28:03 UTC