Social Web Community Group Teleconference

17 Jan 2018

Attendees

Present: cwebber2, puckipedia, melody, pfrazee
Regrets Chair: cwebber2
Scribe: None

<cwebber2> <pfrazee> if I were to try to build a reliable mail system on top of Dat, one element I'd include is a federated server layer which helps the client discover mail from users that they don't follow. That server could discover the mail by crawling the dat network like a search-engine spider, or it could use a server-to-server signal like activitypub does. (I hope that's illustrative of how dat works.)

<cwebber2> *end paste*

<cwebber2> I guess I should have probably linked to the logs instead

<cwebber2> well anyway!

<cwebber2> the crux here is that AP is designed around mutable side effects, because it's built for a very 2005-2015'ish social networking design

<cwebber2> which isn't bad!

<cwebber2> bad it's a different decision than what many peer to peer, particularly append-only peer to peer, systems of today might take

<cwebber2> is Create / Delete even relevant there? I mean, clearly Like is still relevant

<melody> given that 2005-2015 has been dramatically incapable of effective anti-abuse measures and p2p continues to make that problem worse, i'm not sure we're ready to move on

<puckipedia> melody: well, you as owner of the inbox have the right to just ignore messages that get sent to it in p2p

<puckipedia> somewhat relevant but https://gist.github.com/puckipedia/fcd9c7e12d9d50897b9a16179abbd58a my thoughts on signing, /especially/ in a p2p world

<puckipedia> cwebber2: I think Create still is, but I don't think `Delete` can really do much

<cwebber2> anti-abuse is an interesting axis to explore in a p2p world... I'm also not convinced it's incompatible, given that I think anti-abuse tooling may need to become better controlled by individuals. (append-only structures may make it complicated by keeping abusive messages around... is there a way to filter them out?)

<cwebber2> puckipedia: well, one way to think about it might be like git

<cwebber2> that's an append-only structure, but you both create and delete files in it

<cwebber2> it's "at this time, this file appeared... here it was changed... here it was removed"

<melody> puckipedia: right but censorship-resistance comes at a cost that like, serious harassment such as doxxing are *completely* impossible to remove and third-party moderation just isn't possible which might be a "feature not a bug" but it's a feature that comes at a huge risk for vulnerable populations

<puckipedia> melody: mmm yeah, it'll be like everyone runs their own instance

<puckipedia> cwebber2: okay so assuming you have content-addressed storage, my view of e.g. a collection is a merkle chain, but it's signed by the owner, and the first page is pointed to using a mutable pointer (????)

<puckipedia> the mutable pointer being signed by the user as well, only /they/ can append things into an inbox

<melody> i'm *deeply* suspicious of p2p tech for this reason -- and well-behaved software can hide some of this in the actual user experience the way that like, you could theoretically have a browser extension filter twitter for you despite having no control over the actual feed, the network becomes a source of information for out-of-band attacks

<melody> there's a lot of value in tactical centralization when you have a legitimate need for some kinds of information control

<cwebber2> well, and trying to deal with things on an instance-level may result in the eventual centralization of federated systems

<cwebber2> that's what happened to email, for spam

<cwebber2> I run my own mail server but it's damn hard because the large players decided to mostly just trust the large players

<cwebber2> some level of centralization may be useful but I'm very nervous about heading down that path... IMO what's more important is information-sharing about abusers and abuse patterns and building trust networks. But full caveat to what I just said, none of that has been proven to be a useful route because nobody is investing in the decentralized approach, and that's partly economics: funding for anti-abuse tends to come from large organizations funding

<cwebber2> themselves

<cwebber2> so I dunno

<cwebber2> I'd be interested in what the dat folks think about this

<cwebber2> at any rate, not saying we should pivot all of us to P2P because we're even just trying to get our mutable systems off the ground, but I think it's worth exploring as a direction and trying to understand what it would mean

<melody> if there's an immutable record, all of those approaches are too reactive

<cwebber2> it's true that that's one of several challenges with an immutable record

<pfrazee> I got pinged so I read up on the record. If there's time, I'm happy to respond to this

<melody> if somebody posts revenge porn it's just there forever now, you can record that it's not supposed to be shown but a sufficiently popular network will spawn tools _specifically_ for tracking content that was supposed to have been deleted

<cwebber2> pfrazee: there's time! :)

<pfrazee> broadly- I wouldn't discourage the federated design (2005-2015 arch) from continuing. There are challenges for both designs and I'm glad both are being pursued

<pfrazee> the dat network is a system of "file archives" which are backed by the append-only logs. Most archives are owned by an individual user. In the future, authorship will be shareable, but likely by small groups. Therefore we tend to use a "pull-based" architecture

<melody> wouldn't that mean that content will just disappear when nodes go dark temporarily?

<melody> most useful p2p network designs i've seen incorporate a lot of redundancy to prevent that

<melody> but that redundancy is the danger

<cwebber2> btw, as an aside, speaking of P2P and ActivityPub, here's a video I just saw https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a-4ec8cbdca701

<pfrazee> pull-based means, we only fetch the data which the client asks for. And so our spam and abuse policies are whitelists: by default you are not seen, and your data must be requested. That has scaling limits (no global awareness) but at the moment, it's a benefit because it dodges the question of spam

<cwebber2> PeerTube (a p2p video service) federating with Mastodon over ActivityPub

<pfrazee> melody: yes and our solution for that is to use self-deployable "public peers." User/edge devices are unreliable, but the public peers should stay on. Can be butt servers or run at home. See https://hashbase.io

<puckipedia> isn't this approx what ipfs is doing?

<pfrazee> IPFS has chosen to pursue Filecoin, which is a crypto-currency marketplace for rehosting

<pfrazee> the underlying premise is similar, but they're adding an automated market layer

<melody> ugh

<pfrazee> the dat ecosystem has opted not to use the market layer, we think it's more complexity than is needed

<pfrazee> and, in general, we're against systems that rely on PoW consensus

<pfrazee> about the inability to remove data --

<cwebber2> pfrazee: how do you deal with "motivation" to peer rather than just leech?

<cwebber2> sorry, didn't mean to interrupt :)

<pfrazee> (no worries, will answer in a moment)

<pfrazee> the Dat file-archive abstraction includes deletion. Internally it's an append-only log, and so the reference to the file is never lost. Of course you can't force folks to decache the actual content, but unless users intentionally endeavor to retain the data, their node will delete it automatically

<pfrazee> the concern is not trivial so I don't want to downplay it. Compared to current systems, in Dat the difference is you can never scrub the system of the reference in history

<cwebber2> I'm also worried about the case melody raised about revenge porn... though I'm concerned that making it impossible for a network to ever host that content again might not be possible in any decentralized system... or even in any network which contains an OOB mechanism... but maybe there are ways to punish peers that are seen to be distributing such content?

<pfrazee> cwebber2: certainly possible. Currently on the Dat network, the discovery layer is global and so if you're distributing something, the global network can find out

<puckipedia> activitypubcoin

<cwebber2> puckipedia: lol

<cwebber2> pfrazee: oh that's interesting re: discovery layer being global

<pfrazee> cwebber2: yeah. We currently use a hybrid of 3 tools: LAN multicast, a tracker server, and bittorrent's DHT

<cwebber2> pfrazee: cool :)

<pfrazee> cwebber2: our roadmap is to move to a new DHT, ditch the tracker server, and keep multicast

<cwebber2> pfrazee: I'd like to play with Beaker/Dat more soon... main problem for me is that I'm running a very obscure GNU/Linux distro and so I have to figure out how to build/run it ;)

<cwebber2> (GuixSD)

<pfrazee> cwebber2: about leeching, I'm not sure yet. I'm actually not sure whether I think leeching should be punished. We're using Dat as a dropin replacement to https and there may be users who have very little data available to them. I'd like to investigate whether a culture of intention-based sharing can solve it

<pfrazee> :) let me know how I can help

<cwebber2> pfrazee: yes, sometimes I think that what the bigger de-motivator for P2P file sharing peering was actually the legal *punishment* for sharing

<cwebber2> well, of copyrighted content you didn't have the legal authority to share

<pfrazee> cwebber2: right. I think, so long as we don't aversely affect performance, people will like to contribute

<cwebber2> though, I think associating P2P with just file sharing of restricted copyrighted works is ignoring the many other areas where p2p technology is interesting for :)

<pfrazee> and we're building in controls to the browser UI so you can explicitly contribute. "Rehost for 1 day / 1 week / 1 month / permanently"

<cwebber2> pfrazee: cool!

<melody> that doesn't seem to be the case in practice -- like, the content that is most likely to disappear from the swarm on bittorrent is not the content that is most actively punished for sharing

<pfrazee> melody: fair point

<melody> i've seen linux distros disappear from bittorrent swarms, but movies and music which are actively policed by the RIAA and MPAA stay up forever, and indie films not protected by any distributor die off quickly

<melody> most of that is probably popularity -- content a lot of people want gets shared -- but it drowns out smaller voices

<cwebber2> melody: that's true

<cwebber2> re: smaller voices not staying around as much

<cwebber2> melody: and I did used to download GNU/Linux distros over bittorrent... but one thing I guess I was referring to was how my ISP used to throttle my connection when I would peer

<cwebber2> if I would upload

<cwebber2> as opposed to when I would download

<cwebber2> admittedly I haven't done bittorrenting of distro ISOs for some time :)

<melody> sure, though idk that i've ever had an internet connection with symmetric download/upload

<melody> so that's gonna continue to be an issue for any platform expected to work on end users' internet connections

<cwebber2> indeed, right now we have ISPs wishing to move to a policy where consumers are just consumers ;)

<cwebber2> and that's a challenge for any p2p system

<cwebber2> well, that may be a very US-focused statement, I can't speak for the world

<melody> i know the lack of symmetric connections is not globally true but there are enough internet users in the US that it's still a concern

cwebber2 nods

<cwebber2> btw, we're technically 10 minutes over on time, but this has been a reasonably informal meeting in the sense that we didn't do an audio portion

<melody> i appreciated that i don't have a mumble client on this computer, my normal computer is being repaired

<cwebber2> ah, convenient then! :)

<cwebber2> so do we want to "extend" the official meeting to keep chatting or call this a wrap?

<cwebber2> we can always keep chatting on IRC anyway so I guess it doesn't matter much aside from logging ;)

<cwebber2> which the room is logged anyway, but meeting logs ;)

<melody> I've got no strong opinions

<cwebber2> ok, I think let's call the meeting over :)

<cwebber2> thanks for the good conversation everyone! and feel free to keep chatting :)

<cwebber2> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

SocialCG/2018-01-17/minutes

Social Web Community Group Teleconference

17 Jan 2018

Attendees

Contents

groups and Announce

rackstodon

AP and P2P / append-only structures

Summary of Action Items

Summary of Resolutions