16:01:17 <RRSAgent> RRSAgent has joined #social
16:01:17 <RRSAgent> logging to https://www.w3.org/2018/01/17-social-irc
16:01:19 <trackbot> RRSAgent, make logs public
16:01:19 <Zakim> Zakim has joined #social
16:01:21 <trackbot> Meeting: Social Web Working Group Teleconference
16:01:21 <trackbot> Date: 17 January 2018
16:01:25 <cwebber2> hi hi!
16:01:39 <cwebber2> welcome to the irc-only SocialCG meeting :)
16:01:56 <puckipedia> beep boop
16:01:58 <cwebber2> let's JIT compile this topic list... things I'd love to discuss:
16:02:07 <cwebber2>  - more about what puckipedia is saying about groups
16:02:25 <cwebber2>  - I'm working on a new social client
16:03:29 <cwebber2>  - ActivityPub/ActivityStreams and append-only P2P network structures (ie Dat and Beaker, which pfrazee and taravancil are working on) https://github.com/beakerbrowser/beaker/issues/820
16:03:30 <Loqi> [pfrazee] #820 Application data schemas & how to manage decentralized development
16:03:50 <cwebber2> though I don't think those two can make it to this meeting so :)
16:03:55 <cwebber2> anything else anyone wants to talk about?
16:04:28 <puckipedia> guess not
16:05:14 <cwebber2> so puckipedia, groups and Announce
16:05:24 <cwebber2> I guess the way we'd distinguish this UI-wise from a "share" style announce
16:05:34 <cwebber2> is by recognizing the actor type?
16:05:36 <cwebber2> or?
16:05:47 <puckipedia> yeah, I guess so
16:06:06 <puckipedia> tbh the difference is that a person does it manually, a group does it automatically
16:06:09 <cwebber2> I mean we could always composite type it like {"type": ["Announce", "GroupForward"]} but I think lots of applications are not very aware of the composite type things :)
16:07:20 <puckipedia> so my guess is that e.g. mastodon might show it as "[user] posted to [group]" if you follow the group, and doesn't show the [posted to group] if it's sent to followers & group, and you follow them
16:08:38 <cwebber2> that sounds like a reasonable way to do it
16:09:34 <puckipedia> second of all, this would mean that only Create/Announces into a group would be announced
16:10:06 <puckipedia> I think this is acceptable (and of course, it would follow the audience rules, so a public post could be announced into a group, but private ones have to be Created with an audience containing the audience of the group)
16:11:19 <cwebber2> cool
16:11:27 <cwebber2> puckipedia: any other thoughts on this topic?
16:12:29 <puckipedia> well, I assume Follow'ing a group would add you, and this would also provide a stable mechanism for following a group. That probably also means a group has `followers`, but should e.g. admins of a group be specified in a collection, or implementation defined?
16:12:49 <cwebber2> I think you could have admins be a separate collection
16:12:53 <cwebber2> attached to the group
16:13:28 <KevinMarks_> KevinMarks_ has joined #social
16:14:53 <puckipedia> hm, I guess we could work with something like that, especially being able to Announce, and later Delete that announcement
16:15:36 <puckipedia> and for other servers to differentiate between auto-forwarded and original post
16:15:36 <cwebber2> puckipedia: radical and maybe immediately unpopular idea for groups, feel free to kick me out of this meeting for even suggesting it ;)
16:15:47 <cwebber2> another way to do groups would instead of Announce'ing them
16:15:53 <cwebber2> Add posts to the group, as if a collection
16:15:57 <cwebber2> and then you can always Remove them
16:16:22 <cwebber2> however, this may be more complicated
16:16:29 <puckipedia> means more work for client and server :P
16:16:31 <cwebber2> it's not as simple as an Announce
16:16:31 <cwebber2> yeah
16:16:34 <cwebber2> ok, bad idea!
16:16:37 <cwebber2> was just throwing it out there
16:16:40 <puckipedia> imagine e.g. the GNU Social !group feature
16:16:44 <cwebber2> yeah
16:16:51 <cwebber2> I immediately agree, not the right route :)
16:17:01 <cwebber2> forget I ever said it! ;)
16:18:16 <cwebber2> puckipedia: ok, so... is that it for Groups convo?
16:18:25 <puckipedia> think so yeah
16:18:27 <cwebber2> cool
16:18:44 <cwebber2> ok next topic was... the client I'm working on
16:19:01 <cwebber2> well, there's not much to say I guess since I didn't put the code up
16:19:03 <cwebber2> http://dustycloud.org/tmp/rackstodon_test.png
16:19:05 <cwebber2> it mostly works
16:19:35 <cwebber2> embarassingly, it uses the Mastodon API currently ;)  but I'm switching it over to the AP C2S API and getting it to do transformation between the protocols under the hood soonish
16:19:37 <puckipedia> how well does it work with flattening/unflattening?
16:19:52 <cwebber2> puckipedia: since it's not using the AP API yet I haven't really explored it
16:19:58 <cwebber2> but that's a good question since it'll have to soon
16:20:22 <cwebber2> puckipedia: probably I should get the code up and then test against Kroeg and Pubstrate soon.
16:20:48 <cwebber2> it'll also be an interesting stress-test of the json-ld tooling I just wrote for Racket, lol
16:20:53 <puckipedia> random fun fact, if you add "TU" in your user-agent, all the objects in Kroeg are flat :P
16:21:07 <cwebber2> puckipedia: huhm!  why "TU"?
16:21:26 <puckipedia> because it's a hack for the tiny activitypub client we wrote for a university project :P
16:22:01 <cwebber2> aha :)
16:22:38 <cwebber2> anyway, not much else to say on this... unless we want to expand to other implementation work on this topic
16:22:53 <cwebber2> puckipedia: I know you mentioned you were working on multi-tenancy so maybe that's interesting to talk about, or maybe not? ;)
16:23:07 <puckipedia> eh, not much special :P just internal separation of instances
16:24:00 <KevinMarks> KevinMarks has joined #social
16:24:05 <cwebber2> k :)
16:24:08 <puckipedia> also I think I broke federation between Kroeg instances, hm
16:24:14 <cwebber2> oops!
16:25:00 <puckipedia> I want to try to keep separation as much as possible, to the point you shouldn't quite be able to tell they're running on the same server
16:25:21 <puckipedia> (except of course if you generate a random URL and have it retrieved by both instances, and it shows the same IP and/or is cached)
16:26:46 <puckipedia> that's it basically
16:27:18 <cwebber2> cool :)
16:27:25 <cwebber2> move on to the next topic then?
16:27:43 <puckipedia> sounds good
16:27:44 <cwebber2> AP and P2P / append-only structures!
16:28:06 <cwebber2> unfortunately the main people who have things to contribute to this aren't able to make this meeting, but I do have some thoughts to maybe spill out loud anyway :)
16:28:18 <puckipedia> same, lol
16:28:44 <cwebber2> there's a twitter thread here too:
16:28:53 <cwebber2> oh wait
16:28:57 <cwebber2> nm the content was mostly in here :)
16:29:04 <cwebber2> ok here's the part I think was interesting
16:29:47 <cwebber2> hopefully nobody minds me pasting in our irc-only meeting ;)
16:29:51 <cwebber2> <cwebber2> pfrazee: yeah... so ActivityPub is fairly "side-effect'y"
16:29:51 <cwebber2> <pfrazee> cwebber2: right, sensible for the federated server design
16:29:51 <cwebber2> <cwebber2> we had some discussion, back in the day, about whether or not Create was really needed
16:29:51 <cwebber2> <cwebber2> in some ways it's probably the case that it would be much easier to do a non-side'effect'y design without Create
16:29:53 <cwebber2> <cwebber2> some of the other verbs may still be useful
16:29:53 <cwebber2> <cwebber2> eg Like, even on an append-only datastructure, is still useful
16:29:55 <cwebber2> <pfrazee> right
16:29:57 <cwebber2> <cwebber2> pfrazee: so is there anything else cruft'y aside from Create in a p2p append-only structure context?
16:30:00 <cwebber2> <cwebber2> pfrazee: basically Delete and etc become more informative then
16:30:02 <cwebber2> <cwebber2> so does Update
16:30:04 <cwebber2> <pfrazee> cwebber2: right there'd probably be no need for update or delete. I'll keep reading and mention thoughts as they come to me
16:30:07 <cwebber2> <cwebber2> pfrazee: thanks :)
16:30:09 <cwebber2> <pfrazee> cwebber2: the inbox/outbox differs. In a way, every dat is an outbox, and the inbox is assembled by syncing the followed outboxes.
16:30:12 <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.)
16:30:19 <cwebber2> *end paste*
16:30:21 <cwebber2> I guess I should have probably linked to the logs instead
16:30:23 <cwebber2> well anyway!
16:31:24 <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
16:31:35 <cwebber2> which isn't bad!
16:32:16 <cwebber2> bad it's a different decision than what many peer to peer, particularly append-only peer to peer, systems of today might take
16:32:32 <cwebber2> is Create / Delete even relevant there?  I mean, clearly Like is still relevant
16:32:35 <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
16:33:20 <puckipedia> melody: well, you as owner of the inbox have the right to just ignore messages that get sent to it in p2p
16:33:34 <puckipedia> somewhat relevant but https://gist.github.com/puckipedia/fcd9c7e12d9d50897b9a16179abbd58a my thoughts on signing, /especially/ in a p2p world
16:34:23 <puckipedia> cwebber2: I think Create still is, but I don't think `Delete` can really do much
16:34:29 <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?)
16:34:41 <cwebber2> puckipedia: well, one way to think about it might be like git
16:34:44 <KevinMarks_> KevinMarks_ has joined #social
16:34:50 <cwebber2> that's an append-only structure, but you both create and delete files in it
16:35:02 <cwebber2> it's "at this time, this file appeared... here it was changed... here it was removed"
16:35:04 <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
16:35:32 <puckipedia> melody: mmm yeah, it'll be like everyone runs their own instance
16:36:49 <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 (????)
16:37:16 <puckipedia> the mutable pointer being signed by the user as well, only /they/ can append things into an inbox
16:37:34 <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
16:38:54 <melody> there's a lot of value in tactical centralization when you have a legitimate need for some kinds of information control
16:39:37 <cwebber2> well, and trying to deal with things on an instance-level may result in the eventual centralization of federated systems
16:39:45 <cwebber2> that's what happened to email, for spam
16:40:01 <cwebber2> I run my own mail server but it's damn hard because the large players decided to mostly just trust the large players
16:41:46 <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
16:41:46 <cwebber2> themselves
16:41:57 <cwebber2> so I dunno
16:42:05 <cwebber2> I'd be interested in what the dat folks think about this
16:42:44 <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
16:42:53 <melody> if there's an immutable record, all of those approaches are too reactive
16:43:26 <cwebber2> it's true that that's one of several challenges with an immutable record
16:43:53 <pfrazee> I got pinged so I read up on the record. If there's time, I'm happy to respond to this
16:44:00 <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
16:44:07 <cwebber2> pfrazee: there's time! :)
16:45:26 <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
16:47:18 <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
16:48:20 <melody> wouldn't that mean that content will just disappear when nodes go dark temporarily?
16:48:50 <melody> most useful p2p network designs i've seen incorporate a lot of redundancy to prevent that
16:49:04 <melody> but that redundancy is the danger
16:49:11 <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
16:49:16 <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
16:49:31 <cwebber2> PeerTube (a p2p video service) federating with Mastodon over ActivityPub
16:50:08 <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 cloud servers or run at home. See https://hashbase.io
16:50:34 <puckipedia> isn't this approx what ipfs is doing?
16:50:55 <pfrazee> IPFS has chosen to pursue Filecoin, which is a crypto-currency marketplace for rehosting
16:51:13 <pfrazee> the underlying premise is similar, but they're adding an automated market layer
16:51:28 <melody> ugh
16:51:45 <pfrazee> the dat ecosystem has opted not to use the market layer, we think it's more complexity than is needed
16:51:52 <KevinMarks> KevinMarks has joined #social
16:52:00 <pfrazee> and, in general, we're against systems that rely on PoW consensus
16:52:19 <pfrazee> about the inability to remove data --
16:52:28 <cwebber2> pfrazee: how do you deal with "motivation" to peer rather than just leech?
16:53:09 <cwebber2> sorry, didn't mean to interrupt :)
16:53:15 <pfrazee> (no worries, will answer in a moment)
16:55:28 <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
16:56:32 <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
16:58:53 <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?
16:59:34 <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
16:59:34 <puckipedia> activitypubcoin
16:59:42 <cwebber2> puckipedia: lol
16:59:55 <cwebber2> pfrazee: oh that's interesting re: discovery layer being global
17:00:34 <pfrazee> cwebber2: yeah. We currently use a hybrid of 3 tools: LAN multicast, a tracker server, and bittorrent's DHT
17:00:49 <cwebber2> pfrazee: cool :)
17:00:57 <pfrazee> cwebber2: our roadmap is to move to a new DHT, ditch the tracker server, and keep multicast
17:01:15 <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 ;)
17:01:18 <cwebber2> (GuixSD)
17:01:26 <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
17:01:50 <pfrazee> :) let me know how I can help
17:02:06 <cwebber2> pfrazee: yes, sometimes I think that what the bigger de-motivator for P2P file sharing peering was actually the legal *punishment* for sharing
17:02:24 <cwebber2> well, of copyrighted content you didn't have the legal authority to share
17:02:51 <pfrazee> cwebber2: right. I think, so long as we don't aversely affect performance, people will like to contribute
17:03:18 <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 :)
17:03:21 <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"
17:03:28 <cwebber2> pfrazee: cool!
17:03:30 <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
17:03:53 <pfrazee> melody: fair point
17:04:56 <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
17:05:31 <melody> most of that is probably popularity -- content a lot of people want gets shared -- but it drowns out smaller voices
17:05:37 <cwebber2> melody: that's true
17:05:48 <cwebber2> re: smaller voices not staying around as much
17:06:18 <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
17:06:23 <cwebber2> if I would upload
17:06:30 <cwebber2> as opposed to when I would download
17:07:01 <cwebber2> admittedly I haven't done bittorrenting of distro ISOs for some time :)
17:07:02 <melody> sure, though idk that i've ever had an internet connection with symmetric download/upload
17:07:32 <melody> so that's gonna continue to be an issue for any platform expected to work on end users' internet connections
17:08:07 <cwebber2> indeed, right now we have ISPs wishing to move to a policy where consumers are just consumers ;)
17:08:14 <cwebber2> and that's a challenge for any p2p system
17:08:42 <cwebber2> well, that may be a very US-focused statement, I can't speak for the world
17:09:30 <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
17:10:06 <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
17:10:32 <melody> i appreciated that i don't have a mumble client on this computer, my normal computer is being repaired
17:10:44 <cwebber2> ah, convenient then! :)
17:10:49 <cwebber2> so do we want to "extend" the official meeting to keep chatting or call this a wrap?
17:11:01 <cwebber2> we can always keep chatting on IRC anyway so I guess it doesn't matter much aside from logging ;)
17:11:09 <cwebber2> which the room is logged anyway, but meeting logs ;)
17:12:07 <melody> I've got no strong opinions
17:12:21 <cwebber2> ok, I think let's call the meeting over :)
17:12:38 <cwebber2> thanks for the good conversation everyone!  and feel free to keep chatting :)
17:12:42 <cwebber2> trackbot, end meeting
17:12:42 <trackbot> Zakim, list attendees
17:12:42 <Zakim> As of this point the attendees have been (no one)
17:12:50 <trackbot> RRSAgent, please draft minutes
17:12:50 <RRSAgent> I have made the request to generate https://www.w3.org/2018/01/17-social-minutes.html trackbot
17:12:51 <trackbot> RRSAgent, bye
17:12:51 <RRSAgent> I see no action items
17:12:52 <cwebber2> oops, we never present+'ed ;)
17:12:54 <cwebber2> oh well