#social 2018-01-17
2018-01-17 UTC
rowan, xmpp-social, KevinMarks and ben_thatmustbeme joined the channel
# 
puckipedia thinks about groups a bit more
# puckipedia opinion: I feel like every object that gets Created/Announced into the group's inbox should be /announced/ when repeated
# puckipedia because then the relay of the post has its own ID, and e.g. the owners could revoke a post when it is e.g. offtopic, by having the group send out a `Delete`
# puckipedia also logical place for relay metadata
# puckipedia yeah someone mentioned groups in #mastodon on freenode
# puckipedia <thardin> another nice things with !groups is you can talk about a topic with people you otherwise wouldn't want to follow <thardin> for example I talk about ham radio stuff with one of the admins of sealion.club via my !amateur group. but I wouldn't want to follow the guy because holy cow
KevinMarks joined the channel
# puckipedia I guess, though if it's just us I guess just doing IRC would be good enoughj
# puckipedia ... also I don't have mumble on here yet
RRSAgent joined the channel
# 
RRSAgent logging to https://www.w3.org/2018/01/17-social-irc
Zakim joined the channel
# puckipedia beep boop
# 
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
# puckipedia guess not
# puckipedia yeah, I guess so
# puckipedia tbh the difference is that a person does it manually, a group does it automatically
# 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
# 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)
# 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?
KevinMarks_ joined the channel
# puckipedia hm, I guess we could work with something like that, especially being able to Announce, and later Delete that announcement
# puckipedia and for other servers to differentiate between auto-forwarded and original post
# puckipedia means more work for client and server :P
# puckipedia imagine e.g. the GNU Social !group feature
# puckipedia think so yeah
# puckipedia how well does it work with flattening/unflattening?
# puckipedia random fun fact, if you add "TU" in your user-agent, all the objects in Kroeg are flat :P
# puckipedia because it's a hack for the tiny activitypub client we wrote for a university project :P
# puckipedia eh, not much special :P just internal separation of instances
KevinMarks joined the channel
# puckipedia also I think I broke federation between Kroeg instances, hm
# 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
# puckipedia sounds good
# puckipedia same, lol
# 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.)
# 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?)
KevinMarks_ joined the channel
# 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 (????)
# 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 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
# melody if there's an immutable record, all of those approaches are too reactive
# 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
# 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
# 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
# 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
KevinMarks joined the channel
# pfrazee and, in general, we're against systems that rely on PoW consensus
# pfrazee about the inability to remove data --
# 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
# pfrazee cwebber2: yeah. We currently use a hybrid of 3 tools: LAN multicast, a tracker server, and bittorrent's DHT
# pfrazee cwebber2: our roadmap is to move to a new DHT, ditch the tracker server, and keep multicast
# 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
# pfrazee cwebber2: right. I think, so long as we don't aversely affect performance, people will like to contribute
# 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"
# 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
# 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
# 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
# melody i appreciated that i don't have a mumble client on this computer, my normal computer is being repaired
# melody I've got no strong opinions
# RRSAgent I have made the request to generate https://www.w3.org/2018/01/17-social-minutes.html trackbot
RRSAgent left the channel
# melody semi-related question but are there any mumble clients better than the official one for non-mobile users?
KevinMarks joined the channel
# melody i find it difficult to use but i suppose there's nothing for it
jankusanagi_ and jankusanagi__ joined the channel
Zakim left the channel