16:18:33 RRSAgent has joined #social 16:18:33 logging to https://www.w3.org/2017/12/20-social-irc 16:18:35 RRSAgent, make logs public 16:18:35 Zakim has joined #social 16:18:37 Meeting: Social Web Working Group Teleconference 16:18:37 Date: 20 December 2017 16:18:45 scribenick: eprodrom 16:19:03 eprodrom: we're re-emerging into a more ad-hoc process, this is much more about getting things done rather than protocol meetings... so this is the fun part I think 16:19:25 present+ 16:19:28 present+ 16:19:28 present+ 16:19:29 present+ 16:19:32 present+ BanjoFox 16:19:47 q? 16:20:15 topic: Evan's exciting new ActivityPub projects 16:20:19 scribenick: cwebber2 16:20:31 eprodrom: yes! I've got a set of slides I'd like to share 16:21:00 http://slides.com/evanpro/tags-pub 16:21:27 eprodrom: this is the first time I've talked about hte hashtag server process, so I've found it fairly interesting 16:21:53 Back at my desk for a few minutes :D 16:22:10 eprodrom: the ActivityPub network, if you think about it abstractly it's a web of people and groups and programs that are connected through a social graph that create and consume streams of activities 16:22:19 eprodrom: that's the short and sweet version of what ActivityPub does 16:23:06 eprodrom: hashtags, which are a pretty common model used on social networks, are a light categorization tool that allow us to track conversations outside our social graph. You can follow a person's post, but hashtags are useful as a general namespace, and it's very author-driven hashtag process 16:23:20 eprodrom: the way most federated systems I've seen use hashtags is to have a local hashtag object 16:23:40 eprodrom: for example the slide that shows the object with the hashtag that's on its same server 16:24:20 eprodrom: this is how 90% of them work on the federated social web... the advantages are it's easy and it's distributed. the problem is that it's very fragmented... the serendipity of global conversations doesn't happen because conversations are focused around server rather than social network 16:24:30 eprodrom: it also results in search functionality through also the hash tab 16:24:32 *tag 16:24:53 eprodrom: the more we had public stream hashtags, it caused more centralization on those server 16:24:59 eprodrom: you get network effects that result in supernodes 16:25:27 eprodrom: so if we move to a global hashtag server, instead of a hashtag that's on a local server you have a remote server, and in general people use the same servers 16:25:45 eprodrom: then you also don't need to provide all this functionality on a single server, and you get global search 16:25:54 eprodrom: so those conversations are no longer fragmented, they're in one place 16:25:58 eprodrom: the con is centralization 16:26:13 eprodrom: and any time you have a lot of activities going through a single point, there's also privacy issues 16:26:34 eprodrom: today in 2017/2018 any hashtag in the server... there's a temptation as it grows 16:27:11 eprodrom: tags.pub are interesting because they're first class AP objects... they have inboxes and etc and any time they receive an activity meeting certain criteria they'll reshare that activity 16:28:23 eprodrom: any time they receive it they may reshare it, so if you're interested in #metoo or #blacklivesmatter or #rust, you can follow that hashtag, so you can get updates on a hashtag even if you don't follow that person directly because the hashtag shares that directly. so only thing devs have to do is also address the hashtag object. So when you have to: Public, you'd also ad to: hashtag.pub/...the-tag 16:28:30 eprodrom: that'll distribute in a way that makes sense 16:29:11 eprodrom: if you look at what a tags.pub object looks like, it has inbox/outbox/following/followers, has a public key for http signatures, and it has a liked collection even though it's an empty object 16:29:21 eprodrom: so it looks like a person object 16:30:35 eprodrom: seems to work nicely, seems to work, but does it cause a centralization issue? how can we mitigate the centralization? the main way we do that is by having a back plane of redistributing tag objects. So the trick here is that the tags.pub server is an AS2 object like any object. it also has inbox/outbox/followers/following, and just as any hashtag can reshare any object, the server itself can reshare public content 16:30:47 eprodrom: so it looks like a firehose pushing out anything publicly addressed sent to the server 16:31:03 eprodrom: that lets us set up a network of interrelated hashtag servers that can share all content that comes to them 16:31:27 eprodrom: so I think this is like an NNTP (?) server that can share, and other servers can reshare ones that are tagged, even if on another server 16:31:45 eprodrom: it's an ok scalable system, can maybe scale to dozens/hundreds/maybe thousands of servers 16:31:54 eprodrom: there's some issues with id comparison failing 16:31:58 ? 16:32:08 eprodrom: but if we get to the point where it's not scaling that's fine(?) 16:32:26 eprodrom: so if developers aren't using this model, we're not getting in the local hashtag data... we can look for ways to get that too 16:32:43 eprodrom: I think this is a healthy pattern for the AP network so I have a couple of other slidedecks I'm going to be doing along the same lines 16:33:18 eprodrom: places.pub is for location objects, and I'm looking at puttting Musicbrainz vocbualry with a music.pub or etc, don't have a good domain yet but similar pattern of having objects and having them rebroadcastable and also public 16:33:29 https://tags.pub/ https://gitlab.com/evanp/tags-pub 16:33:31 eprodrom: if you're interested in this project, I have links to tags.pub or to gitlab codebase 16:33:41 eprodrom: any questions? I kind of burned right through this 16:33:57 I don't have any questions ;) 16:34:00 Thanks! 16:34:26 cwebber2: Any interesting design challenges while going through this? 16:35:47 eprodrom: there were a couple of things that were difficult.. getting this design down in a way that made sense was interesting, once I realized that any object on the AP network can be a first class citizen, it makes a lot of other patterns really interesting... being able to do this pattern between servers is really cool, and it works right out of ActivityPub. that's been a tricky part 16:36:11 https://gitlab.com/evanp/activitypub-mock 16:36:25 eprodrom: also I did the implementation in node.js, and testing any of this stuff is really complicated... I actually spent quite a lot of time working on a mock server that implements activitypub in order to be able to test server to server and client to server functionality 16:37:15 eprodrom: so that's the other part of it... we're at an early time with AS2 and AP, and a lot of the infrastructure we need isn't quite there yet. So a lot of the implementors in 2018 I think that'll be a lot of it... is there an AS2 library in Go? is there an AP server/framework in Ruby? A lot of us will be building those things up in 2018 and that'll make building easier in 2019 16:39:54 BanjoFox: how do we connect contributors? 16:40:08 cwebber2: I think rowan, you're doing in Python and collaborating with other users right? 16:40:24 cwebber2: and I think that's part of the SocialCG's space 16:40:55 rowan: yes, Mastodon is doing Ruby, I'm collaborating on some with Python, sometimes it's hard to find others, and IRC has been useful enough... and I was fortunate enough to know Shel and met cwebber that way 16:41:35 BanjoFox: question for me is, is there a current list of people more or less that have raised their hand and said "hey ActivityPub is really cool, I'm doing an implementation in XYZ language" 16:41:42 rowan: gotcha... there's the implementation reports page 16:41:50 https://activitypub.rocks/implementation-report/ 16:42:05 cwebber2: languages are listed at the bottom 16:42:25 cwebber2: it's not a complete answer, since people aren't ready to do IRs if they don't have everything ready 16:42:44 q+ 16:42:49 ack eprodrom 16:42:57 q+ 16:43:54 eprodrom: I was going to suggest maybe have something on activitypub.rocks that's a "here's your links to libraries in different languages"... that would be a quick way to get people started, and that page could also link to "here are the languages we don't have an impleemntation of... if you want to do a PHP based system would be huge, or a drupal system or a wordpress system... those would be a big help, and flagging them out would be 16:43:54 a "bounty for glory" type thing 16:44:23 BanjoFox: I'm primarily interested in how we build things out with Rust 16:44:32 BanjoFox: I got it... my specific interest is in the Aardworlf project and I'd have to ask them where we are at this point... at this point I've written a couple small projects in Rust, so to your point I saw the implementation report and say "that's great... we're working on it?" 16:44:35 Unfortunately I need to leave... 16:44:37 Thanks all! 16:44:50 BanjoFox: I'm not sure what the implementation report is supposed to be, but I'm kind of a head hunter for the people who are there 16:44:53 eprodrom: thank you for coming! 16:45:07 I'll be here in 2 weeks. This is where the fun is. 16:45:12 :) 16:45:23 BanjoFox: how do I find folks who may be interested in coming then 16:46:37 cwebber2: if I were to write up a Getting Started page, how would I get it added to activitypub.rocks ? 16:46:39 cwebber2: I can start putting together that page on activitypub.rocks 16:47:02 melody: is there a distinction between applications and libraries? 16:47:46 melody: if you wanted to do a Ruby implementation of AP, Mastodon isn't a great start because it has so many other things, so maybe we should have a distinction between libraries vs full "tool" applications 16:47:58 rowan: sounds like an important distinction to me, and is why I started on my project 16:48:07 BanjoFox: we're defining a library as the core code to add to the application 16:48:27 https://gitlab.com/dustyweb/activitypub.rocks/blob/master/haunt.scm 16:48:53 melody: I'm looking at what useful distinctions might be for organizing this 16:50:53 cwebber2: I'm working on porting my stuff to Racket, and also rowan you and I should collaborate on ActiviPy 16:53:42 cwebber2: regarding errata, the SocialCG will be taking that on but I think we need people more familiar with the W3C process in order to make progress on that in the meeting 16:53:52 cwebber2: and on that note, good meeting everyone, see you next time! 16:53:55 trackbot, end meeting 16:53:55 Zakim, list attendees 16:53:55 As of this point the attendees have been eprodrom, cwebber, melody, rowan, BanjoFox 16:54:03 RRSAgent, please draft minutes 16:54:03 I have made the request to generate https://www.w3.org/2017/12/20-social-minutes.html trackbot 16:54:04 RRSAgent, bye 16:54:04 I see no action items