From W3C Wiki

Social Web Community Group Teleconference

17 Jan 2018


cwebber2, puckipedia, melody, pfrazee


<cwebber2> hi hi!

<cwebber2> welcome to the irc-only SocialCG meeting :)

<puckipedia> beep boop

<cwebber2> let's JIT compile this topic list... things I'd love to discuss:

<cwebber2> - more about what puckipedia is saying about groups

<cwebber2> - I'm working on a new social client

<cwebber2> - ActivityPub/ActivityStreams and append-only P2P network structures (ie Dat and Beaker, which pfrazee and taravancil are working on)

<Loqi> [pfrazee] #820 Application data schemas & how to manage decentralized development

<cwebber2> though I don't think those two can make it to this meeting so :)

<cwebber2> anything else anyone wants to talk about?

<puckipedia> guess not

  • cwebber2 . o O (the nice thing about IRC-only meetings is I can turn back on my music ;))

groups and Announce

<cwebber2> so puckipedia, groups and Announce

<cwebber2> I guess the way we'd distinguish this UI-wise from a "share" style announce

<cwebber2> is by recognizing the actor type?

<cwebber2> or?

<puckipedia> yeah, I guess so

<puckipedia> tbh the difference is that a person does it manually, a group does it automatically

<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 :)

  • cwebber2 nods

<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

<cwebber2> that sounds like a reasonable way to do it

<puckipedia> second of all, this would mean that only Create/Announces into a group would be announced

<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)

  • cwebber2 nods

<cwebber2> cool

<cwebber2> puckipedia: any other thoughts on this topic?

<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?

<cwebber2> I think you could have admins be a separate collection

<cwebber2> attached to the group

<puckipedia> hm, I guess we could work with something like that, especially being able to Announce, and later Delete that announcement

  • cwebber2 nods

<puckipedia> and for other servers to differentiate between auto-forwarded and original post

<cwebber2> puckipedia: radical and maybe immediately unpopular idea for groups, feel free to kick me out of this meeting for even suggesting it ;)

<cwebber2> another way to do groups would instead of Announce'ing them

<cwebber2> Add posts to the group, as if a collection

<cwebber2> and then you can always Remove them

<cwebber2> however, this may be more complicated

<puckipedia> means more work for client and server :P

<cwebber2> it's not as simple as an Announce

<cwebber2> yeah

<cwebber2> ok, bad idea!

<cwebber2> was just throwing it out there

<puckipedia> imagine e.g. the GNU Social !group feature

<cwebber2> yeah

<cwebber2> I immediately agree, not the right route :)

<cwebber2> forget I ever said it! ;)

<cwebber2> puckipedia: ok, so... is that it for Groups convo?

<puckipedia> think so yeah

<cwebber2> cool

<cwebber2> ok next topic was... the client I'm working on


<cwebber2> well, there's not much to say I guess since I didn't put the code up

<cwebber2> rackstodon_test.png

<cwebber2> it mostly works

<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

<puckipedia> how well does it work with flattening/unflattening?

<cwebber2> puckipedia: since it's not using the AP API yet I haven't really explored it

<cwebber2> but that's a good question since it'll have to soon

<cwebber2> puckipedia: probably I should get the code up and then test against Kroeg and Pubstrate soon.

<cwebber2> it'll also be an interesting stress-test of the json-ld tooling I just wrote for Racket, lol

<puckipedia> random fun fact, if you add "TU" in your user-agent, all the objects in Kroeg are flat :P

<cwebber2> puckipedia: huhm! why "TU"?

<puckipedia> because it's a hack for the tiny activitypub client we wrote for a university project :P

<cwebber2> aha :)

<cwebber2> anyway, not much else to say on this... unless we want to expand to other implementation work on this topic

<cwebber2> puckipedia: I know you mentioned you were working on multi-tenancy so maybe that's interesting to talk about, or maybe not? ;)

<puckipedia> eh, not much special :P just internal separation of instances

<cwebber2> k :)

<puckipedia> also I think I broke federation between Kroeg instances, hm

<cwebber2> oops!

<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

<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)

<puckipedia> that's it basically

<cwebber2> cool :)

<cwebber2> move on to the next topic then?

<puckipedia> sounds good

<cwebber2> AP and P2P / append-only structures!

AP and P2P / append-only structures

<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 :)

<puckipedia> same, lol

<cwebber2> there's a twitter thread here too:

<cwebber2> oh wait

<cwebber2> nm the content was mostly in here :)

<cwebber2> ok here's the part I think was interesting

<cwebber2> hopefully nobody minds me pasting in our irc-only meeting ;)

<cwebber2> <cwebber2> pfrazee: yeah... so ActivityPub is fairly "side-effect'y"

<cwebber2> <pfrazee> cwebber2: right, sensible for the federated server design

<cwebber2> <cwebber2> we had some discussion, back in the day, about whether or not Create was really needed

<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

<cwebber2> <cwebber2> some of the other verbs may still be useful

<cwebber2> <cwebber2> eg Like, even on an append-only datastructure, is still useful

<cwebber2> <pfrazee> right

<cwebber2> <cwebber2> pfrazee: so is there anything else cruft'y aside from Create in a p2p append-only structure context?

<cwebber2> <cwebber2> pfrazee: basically Delete and etc become more informative then

<cwebber2> <cwebber2> so does Update

<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

<cwebber2> <cwebber2> pfrazee: thanks :)

<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.

<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 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

<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

<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]