#activitystreams — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #activitystreams, aggregated by home.social.
-
In theory you can do anything you want, and in practice people do that too. As long as you don't break anything that #ActivityPub specs prescribe, the #ActivityStreams vocabulary is just a 'toolbox' of #SocialWeb primitives you can use as building blocks in your solution. The only issue arises if you want your mechanism to have #interoperability with other #fediverse solutions. They should either ignore, or understand it, and not break. Writing a #FEP is the best-practice way to walking the path of adoption of your approach.
-
In theory you can do anything you want, and in practice people do that too. As long as you don't break anything that #ActivityPub specs prescribe, the #ActivityStreams vocabulary is just a 'toolbox' of #SocialWeb primitives you can use as building blocks in your solution. The only issue arises if you want your mechanism to have #interoperability with other #fediverse solutions. They should either ignore, or understand it, and not break. Writing a #FEP is the best-practice way to walking the path of adoption of your approach.
-
I personally find mastodon subpar (which is the reason why I hang out more on lemmy instead)
I'd reckon that all the apps by Mike are really good. But I'd like to know, if I had to choose one, which one should I choose? I was looking at forte, but unfortunately I cannot selfhost, and there are no public instances allowing signup
I mostly want the following:
- lemmy interop (should work for THEM)
- peertube interop (see above)
- pixelfed interop (see above)
- a facebook like experienceI really love the 'social' aspect of facebook, reddit too. I want something like that
So which one has servers I can create an account on? Because god this sounds like something I'd love to use on a daily basis
#fediverse #activitypub #forte #streams #mastodon #hubzilla #friendica #activitystreams
-
I personally find mastodon subpar (which is the reason why I hang out more on lemmy instead)
I'd reckon that all the apps by Mike are really good. But I'd like to know, if I had to choose one, which one should I choose? I was looking at forte, but unfortunately I cannot selfhost, and there are no public instances allowing signup
I mostly want the following:
- lemmy interop (should work for THEM)
- peertube interop (see above)
- pixelfed interop (see above)
- a facebook like experienceI really love the 'social' aspect of facebook, reddit too. I want something like that
So which one has servers I can create an account on? Because god this sounds like something I'd love to use on a daily basis
#fediverse #activitypub #forte #streams #mastodon #hubzilla #friendica #activitystreams
-
@Edent nice article!
I notice you didn't mention as:Place in #ActivityStreams vocab. In your previous article you mentioned "there is good news and bad news" around as:Place, and I deduced the bad news was that Mastodon didn't support it.
Regarding the #SWICG #GeoSocial task force proposal, you wrote:
> The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.
In both the observation on Mastodon support and mention of a geotagged *post* there's an implicit assumption on the application domains this pertains to: (micro)blogging social media.
I gather that the range of business/app domains that may have geosocial capabilities is much broader than that. And while a list of generic use cases can be brainstormed for support, things will be quite solution-specific. And the TF perhaps better provide good guidance and building blocks for that.
Broader question is whether fedi is already tied shut in a microblogging straitjacket.
-
@Edent nice article!
I notice you didn't mention as:Place in #ActivityStreams vocab. In your previous article you mentioned "there is good news and bad news" around as:Place, and I deduced the bad news was that Mastodon didn't support it.
Regarding the #SWICG #GeoSocial task force proposal, you wrote:
> The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.
In both the observation on Mastodon support and mention of a geotagged *post* there's an implicit assumption on the application domains this pertains to: (micro)blogging social media.
I gather that the range of business/app domains that may have geosocial capabilities is much broader than that. And while a list of generic use cases can be brainstormed for support, things will be quite solution-specific. And the TF perhaps better provide good guidance and building blocks for that.
Broader question is whether fedi is already tied shut in a microblogging straitjacket.
-
Regarding the why: When coding Mastodon, Eugen used those parts of the #ActivityPub and #ActivityStreams standards he found useful. For functionality that was not (yet) covered by those standards, he came up with his own solutions and made them part of the Mastodon API which can be considered a quasi-standard now.
When Mastodon was a one person shop, this was a pragmatic way to make progress fast. Standardization bodies are famous for moving slowly, and maybe Eugen was also put off by some of the more eccentric personalities in the ActivityPub community. Now that Mastodon (the organisation) has grown, they should assume a more active role in standards bodies. Perhaps they have – I have not followed these processes closely in recent years.
At any rate, I think it is fair to say that the Mastodon makers and the Fediverse standards community have had a difficult relationship. This is my impression from visiting FediCamp and FediDay events (where Mastodon makers were absent), and some reading in the ActivityPub community forum, e.g.:
https://socialhub.activitypub.rocks/t/mastodon-monoculture-problem/3189/11
https://socialhub.activitypub.rocks/t/discussion-mastodon-and-the-fediverse/1967 -
Regarding the why: When coding Mastodon, Eugen used those parts of the #ActivityPub and #ActivityStreams standards he found useful. For functionality that was not (yet) covered by those standards, he came up with his own solutions and made them part of the Mastodon API which can be considered a quasi-standard now.
When Mastodon was a one person shop, this was a pragmatic way to make progress fast. Standardization bodies are famous for moving slowly, and maybe Eugen was also put off by some of the more eccentric personalities in the ActivityPub community. Now that Mastodon (the organisation) has grown, they should assume a more active role in standards bodies. Perhaps they have – I have not followed these processes closely in recent years.
At any rate, I think it is fair to say that the Mastodon makers and the Fediverse standards community have had a difficult relationship. This is my impression from visiting FediCamp and FediDay events (where Mastodon makers were absent), and some reading in the ActivityPub community forum, e.g.:
https://socialhub.activitypub.rocks/t/mastodon-monoculture-problem/3189/11
https://socialhub.activitypub.rocks/t/discussion-mastodon-and-the-fediverse/1967 -
Linked Data in HTTP Headers rather than in JSON (i.e., JSON-LD), etc
⁂
Many Fediverse servers will give you different content depending on the "Accept" header in the HTTP request.
If "application/activity+json" you get ActivityPub/ActivityStreams JSON-LD metadata. If something else, you get actual file/payload.
If we encoded Linked Data as HTTP headers (key-value pairs), we could include the Linked Data with the actual file/payload.
-
Linked Data in HTTP Headers rather than in JSON (i.e., JSON-LD), etc
⁂
Many Fediverse servers will give you different content depending on the "Accept" header in the HTTP request.
If "application/activity+json" you get ActivityPub/ActivityStreams JSON-LD metadata. If something else, you get actual file/payload.
If we encoded Linked Data as HTTP headers (key-value pairs), we could include the Linked Data with the actual file/payload.
-
acct-URI like URI for content
⁂
We have acct-URI for referring to actors.
Ex: acct:[email protected]
We resolve this to an HTTP-URI using WebFinger.
⁂
We don't have an acct-URI like URI for referring to an actor's content.
Which would also be resolved with WebFinger.
Ex: obj:[email protected]/file.ext
⁂
I think there are many advantages to being able to refer to content separate from where it is stored.
-
acct-URI like URI for content
⁂
We have acct-URI for referring to actors.
Ex: acct:[email protected]
We resolve this to an HTTP-URI using WebFinger.
⁂
We don't have an acct-URI like URI for referring to an actor's content.
Which would also be resolved with WebFinger.
Ex: obj:[email protected]/file.ext
⁂
I think there are many advantages to being able to refer to content separate from where it is stored.
-
Merging ActivityStreams Core & Vocabulary
It looks like there is an effort to try to merge the ActivityStreams Core specification with the ActivityStreams Vocabulary specification into a single specification 🎉
https://github.com/w3c/activitystreams/issues/707
...
(I think this merged specification should also rename "Activity Streams" (with a space) to "ActivityStreams" (without a space).)
-
Merging ActivityStreams Core & Vocabulary
It looks like there is an effort to try to merge the ActivityStreams Core specification with the ActivityStreams Vocabulary specification into a single specification 🎉
https://github.com/w3c/activitystreams/issues/707
...
(I think this merged specification should also rename "Activity Streams" (with a space) to "ActivityStreams" (without a space).)
-
Apparently there is another social-networking protocol (that is not ActivityPub) that uses ActivityStreams, named:
Distributed Social Networking Protocol (DSNP)
...
https://en.wikipedia.org/wiki/Distributed_Social_Networking_Protocol
https://web.archive.org/web/20130910101658/http://www.complang.org/pipermail/dsnp-interest/
-
Apparently there is another social-networking protocol (that is not ActivityPub) that uses ActivityStreams, named:
Distributed Social Networking Protocol (DSNP)
...
https://en.wikipedia.org/wiki/Distributed_Social_Networking_Protocol
https://web.archive.org/web/20130910101658/http://www.complang.org/pipermail/dsnp-interest/
-
The (over)use of "mastodon" is understandable. Mastodon played a pioneering role in implementing microblogging use cases with the #ActivityPub protocol and is also the most mature product at this point in that 'business domain'. Establishing itself as a brand.
#Fediverse is not a very descriptive name to people unfamiliar with it and the idea that it provides access to many apps that integrate with on a single social network (ideally) interoperably is foreign. They are used to 'platform thinking'. Fediverse weaves a social fabric that allows you to be "social together with others" online.
The europa.eu website now has a #Mastodon icon in its social channel list, that hides all that.
Perhaps most communicative is the name #ActivityStreams (name of W3C standard vocabulary of social actions to support). Then a person would subscribe to EU's activity streams and receive Posts, Articles, Videos, Events, Policies, News. Every service the EU offers adds to the stream.
-
The (over)use of "mastodon" is understandable. Mastodon played a pioneering role in implementing microblogging use cases with the #ActivityPub protocol and is also the most mature product at this point in that 'business domain'. Establishing itself as a brand.
#Fediverse is not a very descriptive name to people unfamiliar with it and the idea that it provides access to many apps that integrate with on a single social network (ideally) interoperably is foreign. They are used to 'platform thinking'. Fediverse weaves a social fabric that allows you to be "social together with others" online.
The europa.eu website now has a #Mastodon icon in its social channel list, that hides all that.
Perhaps most communicative is the name #ActivityStreams (name of W3C standard vocabulary of social actions to support). Then a person would subscribe to EU's activity streams and receive Posts, Articles, Videos, Events, Policies, News. Every service the EU offers adds to the stream.
-
Stable Outbox Collection Pages
5/
To me,, having the newest page of the collection be varying length one feels like a better strategy.
-
Stable Outbox Collection Pages
5/
To me,, having the newest page of the collection be varying length one feels like a better strategy.
-
Stable Outbox Collection Pages
4/
BUT, if instead — if the page with 3 items contains the 3 newest items, then —
Only the newest page would have to be recached. I.e., only 1 page churns not all.
All the other collection pages stay as is, and any cached copies of them are still valid.
Etc.
-
Stable Outbox Collection Pages
4/
BUT, if instead — if the page with 3 items contains the 3 newest items, then —
Only the newest page would have to be recached. I.e., only 1 page churns not all.
All the other collection pages stay as is, and any cached copies of them are still valid.
Etc.
-
Stable Outbox Collection Pages
3/
If the page with 3 items contains the 3 oldest items, then —
Every time a new items is added to the collection, then every single collection page will change. I.e., they all churn.
Which means that all cached copies of any collection pages will be invalidated.
Which means a static site generator will have to regenerate all of them again.
Etc.
BUT, if instead —
-
Stable Outbox Collection Pages
3/
If the page with 3 items contains the 3 oldest items, then —
Every time a new items is added to the collection, then every single collection page will change. I.e., they all churn.
Which means that all cached copies of any collection pages will be invalidated.
Which means a static site generator will have to regenerate all of them again.
Etc.
BUT, if instead —
-
Stable Outbox Collection Pages
2/
Let's say a collection has 23 items, and each page 10 items in length.
That means you will have 2 pages with 10 items and 1 page with 3 items.
Should that page with 3 items be the 3 newest items or the 3 oldest items.
The choice affects caching and static site ease quite a bit.
Here is the answer...
-
Stable Outbox Collection Pages
2/
Let's say a collection has 23 items, and each page 10 items in length.
That means you will have 2 pages with 10 items and 1 page with 3 items.
Should that page with 3 items be the 3 newest items or the 3 oldest items.
The choice affects caching and static site ease quite a bit.
Here is the answer...
-
Stable Outbox Collection Pages
1/
ActivityPub uses collections for a number of things:
• followers
• following
• inbox
• outboxAnd, rather than dump everything in the collection into a single document, ActivityPub paginates using collection pages.
That's great.
But, how you divide up a collection into pages matters and affects things. Such as: caching.
I'll explain.
-
Stable Outbox Collection Pages
1/
ActivityPub uses collections for a number of things:
• followers
• following
• inbox
• outboxAnd, rather than dump everything in the collection into a single document, ActivityPub paginates using collection pages.
That's great.
But, how you divide up a collection into pages matters and affects things. Such as: caching.
I'll explain.
-
Something missing from 'followers' and 'following' collections.
2/
I think this could be addressed by using the ActivityPub 'published' field:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-published
Such as what is shown in the (new) attached screen-shot.
So that the date-time when person A followed person B is included.
-
Something missing from 'followers' and 'following' collections.
2/
I think this could be addressed by using the ActivityPub 'published' field:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-published
Such as what is shown in the (new) attached screen-shot.
So that the date-time when person A followed person B is included.
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
-
Here is my work-in-progress FEP for using JSON Resume with ActivityPub:
FEP-6158: ActivityPub 'Resume' Object: JSON Resume expressed as JSON-LD
https://codeberg.org/reiver/fep/src/branch/fep-6158/fep/6158/fep-6158.md
I prefer to write for clarity, so it still needs work.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONResume #fep6158 #fep_6158
-
Here is my work-in-progress FEP for using JSON Resume with ActivityPub:
FEP-6158: ActivityPub 'Resume' Object: JSON Resume expressed as JSON-LD
https://codeberg.org/reiver/fep/src/branch/fep-6158/fep/6158/fep-6158.md
I prefer to write for clarity, so it still needs work.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONResume #fep6158 #fep_6158
-
I may have written a JSON-LD schema for JSON Resume.
It is defined in terms of ActivityPub.
For example:'Resume' is a sub-type of an ActivityPub 'Object'. There are some new fields defined. Etc.
...
Now the question is — where do I put it?
Do I create a pull-request to the JSON Resume resume-schema repo?
Do I create a FEP?
Do I put it somewhere else?
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
I may have written a JSON-LD schema for JSON Resume.
It is defined in terms of ActivityPub.
For example:'Resume' is a sub-type of an ActivityPub 'Object'. There are some new fields defined. Etc.
...
Now the question is — where do I put it?
Do I create a pull-request to the JSON Resume resume-schema repo?
Do I create a FEP?
Do I put it somewhere else?
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
My personal desire would be to create a format from scratch (because you are in control, you get something bespoke to your needs, and it is personally satisfying), but —
I think there is probably an advantage to using something (such as JSON resume) that already has wide adoption.
I guess that makes me inclined towards the latter.
...
So, if I go that way, I would have to decide: plain JSON or JSON-LD.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
My personal desire would be to create a format from scratch (because you are in control, you get something bespoke to your needs, and it is personally satisfying), but —
I think there is probably an advantage to using something (such as JSON resume) that already has wide adoption.
I guess that makes me inclined towards the latter.
...
So, if I go that way, I would have to decide: plain JSON or JSON-LD.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
RE: https://mastodon.social/@reiver/116597879302607072
More on a resume / CV on the Fediverse on Social Web.
Another option could be to use something like "JSON resume":
https://github.com/jsonresume/resume-schema/blob/master/job-schema.json
It seems to be popular.
It isn't JSON-LD. Although I think it would be straightforward to translate it to JSON-LD, if that was desired.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
RE: https://mastodon.social/@reiver/116597879302607072
More on a resume / CV on the Fediverse on Social Web.
Another option could be to use something like "JSON resume":
https://github.com/jsonresume/resume-schema/blob/master/job-schema.json
It seems to be popular.
It isn't JSON-LD. Although I think it would be straightforward to translate it to JSON-LD, if that was desired.
#ActivityPub #ActivityStreams #FediDev #ProToGo #JSONLD #JSONresume
-
On Tags (including Hash-Tags) in ActivityPub.
2/
A new version of ActivityPub could extend the type of "tag" from:
Object | Link
to:
Object | Link | xsd:string
And that would make the following valid ActivityPub:
"tag": ["apple", "banana", "cherry"]
Of course, it would have to be specified how to interpret this. (Ex: as "type":"Hashtag", or whatever.)
#ActivityPub #ActivityStreams #FediDev #HashTag #HashTags #Tag #Tags
-
On Tags (including Hash-Tags) in ActivityPub.
2/
A new version of ActivityPub could extend the type of "tag" from:
Object | Link
to:
Object | Link | xsd:string
And that would make the following valid ActivityPub:
"tag": ["apple", "banana", "cherry"]
Of course, it would have to be specified how to interpret this. (Ex: as "type":"Hashtag", or whatever.)
#ActivityPub #ActivityStreams #FediDev #HashTag #HashTags #Tag #Tags
-
On Tags (including Hash-Tags) in ActivityPub.
1/
I think new developers coming to ActivityPub want to write something like:
"tag": ["apple", "banana", "cherry"]
It is unfortunate that that isn't valid ActivityPub. But, that it must instead be:
"tag": [
{
"type": "Hashtag",
"name": "#apple"
},
{
"type": "Hashtag",
"name": "#banana"
},
{
"type": "Hashtag",
"name": "#cherry"
}
]...
#ActivityPub #ActivityStreams #FediDev #HashTag #HashTags #Tag #Tags
-
On Tags (including Hash-Tags) in ActivityPub.
1/
I think new developers coming to ActivityPub want to write something like:
"tag": ["apple", "banana", "cherry"]
It is unfortunate that that isn't valid ActivityPub. But, that it must instead be:
"tag": [
{
"type": "Hashtag",
"name": "#apple"
},
{
"type": "Hashtag",
"name": "#banana"
},
{
"type": "Hashtag",
"name": "#cherry"
}
]...
#ActivityPub #ActivityStreams #FediDev #HashTag #HashTags #Tag #Tags
-
RE: https://mastodon.social/@reiver/116597841178183282
There is also the other question of — would the resume / CV be JSON-LD.
On one hand, if it was in JSON-LD, it would make it machine-legible similar to ActivityPub.
On the other hand, I don't think anyone is going to write JSON-LD (especially HTML embedded in a JSON string value) by hand. But, I do think some people will want to write their resume by hand.
It feels like user-experience is fighting with JSON-LD based machine-legibility.
-
RE: https://mastodon.social/@reiver/116597841178183282
There is also the other question of — would the resume / CV be JSON-LD.
On one hand, if it was in JSON-LD, it would make it machine-legible similar to ActivityPub.
On the other hand, I don't think anyone is going to write JSON-LD (especially HTML embedded in a JSON string value) by hand. But, I do think some people will want to write their resume by hand.
It feels like user-experience is fighting with JSON-LD based machine-legibility.
-
How could you represent a resume / CV on the Fediverse and Social Web? Where would you put it? Etc?
I think it is tempting to put the whole resume in the Actor document.
But, it is probably better for the Actor document to point (rather than include) it. And, have the resume / CV live somewhere else.
It should probably be done in a way that let's people have multiple resumes / CV. For example, for different roles / career tracks, etc.
-
How could you represent a resume / CV on the Fediverse and Social Web? Where would you put it? Etc?
I think it is tempting to put the whole resume in the Actor document.
But, it is probably better for the Actor document to point (rather than include) it. And, have the resume / CV live somewhere else.
It should probably be done in a way that let's people have multiple resumes / CV. For example, for different roles / career tracks, etc.
-
Remote Inbox Architecture
2/
The Remote Inbox server deals with incoming activities, objects, etc, from other users..
The front-end can get the inbox (and other feeds') data from the Remote Inbox server.
(You'd probably want to store cached data from the Fediverse elsewhere from these two servers, as I've said before. But, that is a separate thread.)
-
Remote Inbox Architecture
2/
The Remote Inbox server deals with incoming activities, objects, etc, from other users..
The front-end can get the inbox (and other feeds') data from the Remote Inbox server.
(You'd probably want to store cached data from the Fediverse elsewhere from these two servers, as I've said before. But, that is a separate thread.)
-
Remote Inbox Architecture
1/
This, the Remote Inbox Architecture, is an architecture for a Fediverse back-end server that I think could be useful.
Here is how it works — there are (at least) 2 servers involved: (1) the main back-end server, and (2) a remote inbox server.
The actor file on main back-end server "points" the inbox to the remote server.
It separates the user's content from the front-end related functionality
...
-
Remote Inbox Architecture
1/
This, the Remote Inbox Architecture, is an architecture for a Fediverse back-end server that I think could be useful.
Here is how it works — there are (at least) 2 servers involved: (1) the main back-end server, and (2) a remote inbox server.
The actor file on main back-end server "points" the inbox to the remote server.
It separates the user's content from the front-end related functionality
...
-
On moving an actor's content.
4/
Or, instead of using the ActivityPub 'Update' activity —
Couldn't we use the ActivityPub 'Move' activity.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-move
With the "origin" and "target" fields.
Where "origin" contains the old ID URL, and "target" contains the new ID URL.
.
-
On moving an actor's content.
4/
Or, instead of using the ActivityPub 'Update' activity —
Couldn't we use the ActivityPub 'Move' activity.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-move
With the "origin" and "target" fields.
Where "origin" contains the old ID URL, and "target" contains the new ID URL.
.
-
On moving an actor's content.
3/
There a many different conventions we could come up with to allow an ActvityPub 'Update' activity to be used to change an object's "id" field.
We (the Fediverse developer community) just need to pick one that everyone is willing to implement.
For example, perhaps the "origin", "result", or "target" field should be used:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-origin
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-target
Or —
...
-
On moving an actor's content.
3/
There a many different conventions we could come up with to allow an ActvityPub 'Update' activity to be used to change an object's "id" field.
We (the Fediverse developer community) just need to pick one that everyone is willing to implement.
For example, perhaps the "origin", "result", or "target" field should be used:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-origin
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-target
Or —
...
-
On moving an actor's content.
2/
Could an ActivityPub 'Update' activity be used to move objects from one server to another server?
Could an 'Update' activity be used to change an object's "id" field?
After all, the "id" is used to identity what is being changed. It is the targeting mechanism.
How can you provide the old "id" to target the (old) object you want to change the "id" of, while also providing a new "id"?
https://www.w3.org/TR/activitypub/#update-activity-inbox
...