1, 2, 1, 2.
All right, so we are exactly on time for Evan to talk to us about taxile up.
Thanks, everybody.
How you doing?
Hey, Paul, if you're here, okay, get ready to go,
because we're trying to do the lightning style.
Yeah, so I'm going to talk to you about tax.gov.
My name is Evan Podromo.
I'm the research director at the social web foundation.
I don't know what you look.
This is my former friend, the mustache.
I'm the co-author and current editor of the Activity Pub and Activity
Streams 2.0 specifications at the W3C.
I wrote the Activity Pub Programming for the social web book for O'Reilly.
That is my Fediver's handle.
My webfinger, you can find me and follow me there.
It's nice and long.
Evan Podromo at socialwebfoundation.org.
I'm going to be talking about a project called Tax.gov,
which is a domain name.
However, if you go there right now, you're going to get some weird website.
It doesn't exist yet, or maybe one of those like website doesn't exist.
This is the link to find it.
It's on GitHub under social web foundation.
Tax.gov.
So I just wanted to warn you before you go in there.
So hashtags. They are so great.
Hashtags are a really wonderful part of social networking.
They give us a chance to coalesce around topics and ideas,
concepts and movements instead of just connecting to other people.
So they're an extremely important part of what makes social networks
and social media special.
However, on the Fediver's, we have mechanisms for following hashtags.
But not everybody knows this.
They're kind of random.
When you're following a hashtag, you're not really following the hashtag
across the whole Fedivers.
You're following a certain subset of content that's been tagged
with that hashtag.
So if you're a person A in this picture,
and you're on the same server, does this make sense as metaphor?
You're on servers.
You got people on servers that make sense?
So A is on a server with B, and B follows C.
So if C posts something under a hashtag, A is going to see it.
If she follows that hashtag, right?
So as long as we have a follow connection between two servers,
those hashtags are followable.
However, if there's no follow connection,
like here across to the DNE server,
that anything that E posts under the same hashtag
won't go to A's inbox.
That makes sense.
So we have to have a follow connection between the servers
in order to follow a hashtag across the Fedivers.
Well, that's kind of suboptimal because we're trying to connect
those communities across the Fedivers.
So one way to work on this to solve it is to give those hashtags
their own accounts on the Fedivers, on a separate server.
This way, a person A can follow that hashtag on that separate server,
and it's like as if she was following a real person.
Thank you.
And so the hashtags server can coalesce information
through back channels from those other servers.
And we aren't depending on social connections between people
in order to propagate the hashtag content.
So that's the idea behind tags.pub.
That we give a hashtag its own account on the Fedivers
that you can follow just like you follow a person.
Like if you're following the hashtag hashtag,
you would follow the hashtag at tags.pub system.
Now, you might get a little spooked about what we're doing.
There's nothing scary going on here.
We're not sputtering, we're not doing mass following,
we're not scraping, we're just using existing interfaces
that are already used for sharing data across servers.
And these are opt-in systems that servers choose the participate in.
It's not an issue where they don't have consent.
So the idea of bringing these servers together
is things like relay interfaces.
We have a special endpoint that's built into activity pub
for delivering public consent.
We are looking at per service APIs.
Mostly I'm not excited about that, which you can see by my emoji,
although some of the fast work might be interesting here too.
Suffice it to say that we're going to be using pretty good systems
that are opt-in and that are not forcing anyone to participate
in a process that they're not interested in.
The technology stack that tags that pub is built on,
it's built on activity pub bot server,
which is a server-side framework for my book.
It uses activity streams at PM library.
Thank you, James Snell, author of activity streams.
It uses a big postgres SQL database,
some love, a lot of hubris.
So the way it works, when we get create activities,
this is where I go into activity pub,
most people look at falsely real quick.
We get create activities.
We take all the tags that are in the object,
and we broadcast out from each of those tags.
So we announce out from each of those tags.
When we get an update, we announce some, we unenounce others.
We're just taking a delta.
We're making sure that we're keeping things up to date with that object.
If something gets deleted, we unenounce it,
so it goes off the network,
and we re-enounce activities as if they were create activities.
So it's a very straightforward use of activity pub.
We are focusing on privacy.
Mostly using public data with the expectation
that if you post on a hashtag publicly,
your intent is to share out with that community.
We are using privacy respecting announce activities.
So we only use links.
So these are very, these respect blocking.
So we will not expose your content to someone you've blocked
through this announced mechanism.
So this is not, so this is a very privacy respecting system.
We're not storing any content.
We're just getting the content,
taking the hashtags, and re-sending out the announce activities,
and perfect.
We're not doing a search index.
We do have an opt-out mechanism,
and we have free and open source software as our code base.
So our hope is that we get that well examined
in case there's any concerns.
We will be launching this system in March 2022.
We're going to be working with server operators to figure out
the best ways to share data.
I've already started talking to a number of them.
If I haven't talked to you, come talk to me.
And then we're documenting interfaces
to make it easier for folks to submit.
And now question.
We have 30 seconds.
One minute.
30 seconds of questions.
So I got one question and then pull.
Because we're in this sprint of three short talks.
We've got so much time for questions.
I find it nice with the text, but question is,
why do you not extend it for more data?
For example, in friendica, we've got possibilities to filter
for stuff like offer name, offer platform, network types,
stuff like that, and what, why?
Can we, can this be extended to some kind of relay?
System that could be done with really filters.
I also posted this on the social hub,
and stuff had a suggestion there.
Okay.
Sorry.
I'm not going to read something.
But what was the question you wanted to find out?
Are there other content types?
No, it's not only for text,
question is, is this be expanded to more search terms,
like all the name, all the platforms,
stuff like that, all the content.
We're not building a search system.
We're building a tag just tags.
That's the intent.
Yeah.
Okay.
We could discuss maybe in a few minutes or whatever.
Okay.
I've got very extended ideas.
Okay.
Thank you.