<cwebber2> scribenick: eprodrom
<cwebber2> 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
<cwebber2> scribenick: cwebber2
eprodrom: yes! I've got a set of slides I'd like to share
<eprodrom> http://slides.com/evanpro/tags-pub
eprodrom: this is the first time I've talked about hte hashtag server process, so I've found it fairly interesting
<BanjoFox> Back at my desk for a few minutes :D
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
... that's the short and sweet version of what ActivityPub
does
... 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
... the way most federated systems I've seen use hashtags is to
have a local hashtag object
... for example the slide that shows the object with the
hashtag that's on its same server
... 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
... it also results in search functionality through also the
hash tab
*tag
eprodrom: the more we had public
stream hashtags, it caused more centralization on those
server
... you get network effects that result in supernodes
... 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
... then you also don't need to provide all this functionality
on a single server, and you get global search
... so those conversations are no longer fragmented, they're in
one place
... the con is centralization
... and any time you have a lot of activities going through a
single point, there's also privacy issues
... today in 2017/2018 any hashtag in the server... there's a
temptation as it grows
... 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
... 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
... that'll distribute in a way that makes sense
... 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
... so it looks like a person object
... 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
... so it looks like a firehose pushing out anything publicly
addressed sent to the server
... that lets us set up a network of interrelated hashtag
servers that can share all content that comes to them
... 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
... it's an ok scalable system, can maybe scale to
dozens/hundreds/maybe thousands of servers
... there's some issues with id comparison failing
?
eprodrom: but if we get to the
point where it's not scaling that's fine(?)
... 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
... 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
... 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
<eprodrom> https://tags.pub/ https://gitlab.com/evanp/tags-pub
eprodrom: if you're interested in
this project, I have links to tags.pub or to gitlab
codebase
... any questions? I kind of burned right through this
<BanjoFox> I don't have any questions ;)
<eprodrom> Thanks!
<eprodrom> cwebber2: Any interesting design challenges while going through this?
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
<eprodrom> https://gitlab.com/evanp/activitypub-mock
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
... 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
BanjoFox: how do we connect contributors?
cwebber2: I think rowan, you're
doing in Python and collaborating with other users right?
... and I think that's part of the SocialCG's space
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
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"
rowan: gotcha... there's the implementation reports page
https://activitypub.rocks/implementation-report/
<eprodrom> cwebber2: languages are listed at the bottom
<eprodrom> cwebber2: it's not a complete answer, since people aren't ready to do IRs if they don't have everything ready
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
a "bounty for glory" type thing
<eprodrom> BanjoFox: I'm primarily interested in how we build things out with Rust
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?"
<eprodrom> Unfortunately I need to leave...
<eprodrom> Thanks all!
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
eprodrom: thank you for coming!
<eprodrom> I'll be here in 2 weeks. This is where the fun is.
:)
BanjoFox: how do I find folks who may be interested in coming then
<eprodrom> cwebber2: if I were to write up a Getting Started page, how would I get it added to activitypub.rocks ?
cwebber2: I can start putting together that page on activitypub.rocks
melody: is there a distinction
between applications and libraries?
... 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
rowan: sounds like an important distinction to me, and is why I started on my project
BanjoFox: we're defining a library as the core code to add to the application
https://gitlab.com/dustyweb/activitypub.rocks/blob/master/haunt.scm
melody: I'm looking at what useful distinctions might be for organizing this
cwebber2: I'm working on porting
my stuff to Racket, and also rowan you and I should collaborate
on ActiviPy
... 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
... and on that note, good meeting everyone, see you next
time!
trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: eprodrom, cwebber, melody, rowan, BanjoFox Present: eprodrom cwebber melody rowan BanjoFox cwebber2 Found ScribeNick: eprodrom WARNING: No scribe lines found matching ScribeNick pattern: <eprodrom> ... Found ScribeNick: cwebber2 Inferring Scribes: eprodrom, cwebber2 Scribes: eprodrom, cwebber2 ScribeNicks: eprodrom, cwebber2 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 20 Dec 2017 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]