ALT text detailsnumber
In the JSON serialization, a number is similar to that used in most programming languages, except that the octal and hexadecimal formats are not used and that leading zeros are not allowed. In the internal representation, a number is equivalent to either a long or double, depending on if the number has a non-zero fractional part (see [WEBIDL]).
There is a larger discussion about fixed-point numbers versus floating-point numbers.
And that, ALL programming-languages should have fixed-point numbers built into them.
And that, programmers should be warned against using floating-point numbers in all but a set of very specialized situations — where inexact math is OK.
For most programmers in most situations inexact math is NOT OK. And, they should NOT use floating-point numbers.
ALT text detailsThis specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
ALT text detailsnumber
In the JSON serialization, a number is similar to that used in most programming languages, except that the octal and hexadecimal formats are not used and that leading zeros are not allowed. In the internal representation, a number is equivalent to either a long or double, depending on if the number has a non-zero fractional part (see [WEBIDL]).
ALT text detailsnumber
In the JSON serialization, a number is similar to that used in most programming languages, except that the octal and hexadecimal formats are not used and that leading zeros are not allowed. In the internal representation, a number is equivalent to either a long or double, depending on if the number has a non-zero fractional part (see [WEBIDL]).
@reiver it is a good question. It is also a question that is formulated from the perspective on how we currently see the AS/AP fediverse.
> I've seen an ongoing debate between "Note" versus "Article" in #ActivityPub / #ActivityStreams. > When is something a "Note"‽ > When is something an "Article"‽
The question makes sense from the notion of what the current #fediverse is. It makes less sense from the context of AS/AP as described in the protocol specs.
The current fediverse is an evolutionary dead-end for 2 reasons:
1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay.
2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out.
Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with.
To avoid fedi to become less and less attractive to newcomers, we must now consider:
“Why do we want to grow the open social web, and for whom?” -- @ben
Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.
Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.
A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.
On the use of "stream(s)" I did a search in both specs, and it is only very sparsely used in the meaning of a stream rather than an Activity Streams document or object.
One time mentioned as "Activity Streams consumer" in #ActivityStreams core and another mention in the Security considerations section.
> Publishers or Consumers implementing Activity Streams as a stream of public data ..
And twice in #ActivityPub where it says both inbox and outbox where it mentions "the outbox stream", "the inbox stream", and one other mention in definition of "Social API" where it is said to provide a "social stream of the user's actor".
So I would not consider this formal language terminology right now. That said, it would be good to further formalize the concept of a Stream, as it is a higher-order concept that'll help lift discussions out of nitty gritty impl detail territory.
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines.
It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show".
So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.
Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.
A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines.
It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show".
So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines.
It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show".
So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
There's a difference between #ActivityPub the protocol and #fediverse the on-the-wire reality, and in the latter #Mastodon is the post-facto interoperability leader.
For there to be interoperabiity in a particular domain there needs to be agreement on data formats and msg exchanges, and the specs don't provide full coverage nor clear guidance on this. Though #ActivityStreams has a section on use cases it was designed to handle, they aren't fully specified.
Of course it is perfectly fine, and highly encouraged to model a domain in the best possible way, but you won't be "part of the fediverse" until you implement enough of the post-facto Mastodon microblogging interop quirks.
We don't have a good ecosystem-level extension approach, and the #FEP constitutes a best-effort. A bandaid that allows to present a best-practice in hopes it gets further adoption.
@eyeinthesky I am genuinely curious. What do you mean by a "real" schema language? What criteria should it meet?
More specifically, what would constitute successful interoperability for #ActivityPub in line with the aims of #SocialWeb?
#JSONLD is not a schema language. It is used to serialise #ActivityStreams as the primary vocab for exchanging social activities, providing a foundation, and leaves room for extensibility for broad human needs to express social matters.
@eyeinthesky I am genuinely curious. What do you mean by a "real" schema language? What criteria should it meet?
More specifically, what would constitute successful interoperability for #ActivityPub in line with the aims of #SocialWeb?
#JSONLD is not a schema language. It is used to serialise #ActivityStreams as the primary vocab for exchanging social activities, providing a foundation, and leaves room for extensibility for broad human needs to express social matters.
An interesting document that was created for #ActivityStreams primer details "motivating use cases" for the specification, and these are categorized by domain.
The primer also uses "domain" as terminology, and in Extensibility page reads:
> Activity Streams 2.0 extensions aren't self-explanatory or self-executing. It takes documentation and software to turn a pet-adoption schema into actual adoption of dogs and cats. However, ideally, the schema for pet adoptions could (and should) run over existing distribution infrastructure like ActivityPub.
It takes a schema and docs, which describe formats, validation, logic, msg exchanges to define what "app" means. These constitute a 'contract' whenever interoperability comes into play, and must be maintained somewhere discoverable, or all interoperability bets are off (and you get whack-a-mole development, app-by-app).
So, I think an (ActivityPub / ActivityStreams) Activity File COULD be a "good" format for backing-up a single post on the Fediverse, but —
Most (maybe all) extant Fediverse software would need to change a bit. Fediverse software would need to support embedding "everything" in a single Activity File (rather than referring to "everything" else by URLs).
Someone people (including me) would want at least some of the comments / replies to be included in a BackUp for a post.
So, for an Activity File to be a "good" format for a BackUp, a single Activity File would also need to contain (all or selected) the comments / replies to the post.
But — for an Activity File to be a "good" format for a BackUp, there would need to be a way to get the Fediverse software to embed the (non-text) media (such as images, audio, video, etc) into an Activity File.
But — for an Activity File to be a "good" format for a BackUp, there would need to be a way to get the Fediverse software to embed the (non-text) media (such as images, audio, video, etc) into an Activity File.
Now, having said that, I don't think there is anything about ActivityPub / ActivityStreams that "prevents" Fediverse software from not embedding (non-text) media (such as images, audio, video, etc) into an Activity File —
For example, an "Image" Object can contain a ("mediaType" and a) "content" field (rather than an "href" field).
Now, having said that, I don't think there is anything about ActivityPub / ActivityStreams that "prevents" Fediverse software from not embedding (non-text) media (such as images, audio, video, etc) into an Activity File —
For example, an "Image" Object can contain a ("mediaType" and a) "content" field (rather than an "href" field).
If you wanted to BackUp a post on the Fediverse, and all you download was the Activity File (with URLs pointing to the non-text media), then — you lost all the (non-text) media (such as images, audio, video, etc) that were part of the post.
If you wanted to BackUp a post on the Fediverse, and all you download was the Activity File (with URLs pointing to the non-text media), then — you lost all the (non-text) media (such as images, audio, video, etc) that were part of the post.
I think one challenge, in practice, with using an Activity File as a BackUp Format is that — a lot of Fediverse software does NOT embed (non-text) media (such images, audio, video, etc) in the Activity File.
I think one challenge, in practice, with using an Activity File as a BackUp Format is that — a lot of Fediverse software does NOT embed (non-text) media (such images, audio, video, etc) in the Activity File.
I wish there was a facility (native or in any app, ideally as part of the #ActivityStreams objects) where I could make #notes on #toots, like we can make notes about particular accounts.
I have a bunch of stuff #bookmarked; I have a tool that exports and sorts my bookmarks.. but by the time I get around to curating them, half the time I can't remember why I bookmarked something.
I wish there was a facility (native or in any app, ideally as part of the #ActivityStreams objects) where I could make #notes on #toots, like we can make notes about particular accounts.
I have a bunch of stuff #bookmarked; I have a tool that exports and sorts my bookmarks.. but by the time I get around to curating them, half the time I can't remember why I bookmarked something.
ALT text detailsObject types
• Note: On services like Mastodon, Notes are the primary type of status. They contain a message body, attachments, can mention users, and be replies to statuses of any type. Within BookWyrm, Notes can only be created as direct messages or as replies to other statuses.
• Review: A review is a status in response to a book (indicated by the inReplyToBook field), which has a title, body, and numerical rating between 0 (not rated) and 5.
• Comment: A comment on a book mentions a book and has a message body.
• Quotation: A quote has a message body, an excerpt from a book, and mentions a book.
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
ALT text detailsObject types
• Note: On services like Mastodon, Notes are the primary type of status. They contain a message body, attachments, can mention users, and be replies to statuses of any type. Within BookWyrm, Notes can only be created as direct messages or as replies to other statuses.
• Review: A review is a status in response to a book (indicated by the inReplyToBook field), which has a title, body, and numerical rating between 0 (not rated) and 5.
• Comment: A comment on a book mentions a book and has a message body.
• Quotation: A quote has a message body, an excerpt from a book, and mentions a book.
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
ALT text details“[And yet another book that made an argument that was in favor of human universals is] Brent Berlin and Paul Kay’s [book] "Basic Color Terms: Their Universality and Evolution" (1969).”
“by the early 1970s two independent lines of psychological research, culminating in studies conducted among preliterate peoples of New Guinea, had shown that there are universal facial expressions of emotions.”
“Berlin and Kay show that although color classification does vary, it also shows remarkable uniformities: particularly in the sequence in which basic color terms are added to the lexicon.”
“Anthropologists and linguists had long known that the way colors are classified varies from language to language. Careful studies conducted by anthropologists after World War II, such as Harold Conklin’s (1955) study of Hanunóo color words, made the point very clearly.”
“The different sets of words for color in various languages …”
Obviously, beginners are NOT going to do this, but — some power-users may want this level of control.
There are different way this could be done, but — one way might be that power-users could use RDFa to explicitly specify what data from the HTML gets into the ActivityPub / ActivityStreams data.
Again, beginners and typical users would NOT do this.
So, what would be a good user-experience (UX) for power-users be — in a system that automatically creates ActivityPub / ActivityStreams data from HTML and Markdown‽
One thought I had is that power-users could explicitly mark what data from their HTML gets into the ActivityPub / ActivityStreams data (if they want to).
let's demo this with a simple case. say you want to `tag` something that is a `Movie` described by schema.org. the `Movie` declares that it has an `actor` who performed in it.
this is redefining the term `actor` as defined at the top-level by #activitystreams -- where `actor` means who performed an `Activity`, not who performed in a `Movie`.
if the activitystreams context was protected, then this would be a fatal error for any #jsonld validator. you cannot be sure which `actor` was meant!
say you have a generic property whose range is relatively unbounded -- a grab-bag where anything goes. something like how `attachment` or `tag` are used in #activitystreams. using multiple contexts at the top-level introduces a potential conflict in terms. you could reconcile any conflicts with a custom context, but that prevents reuse / understanding a more well-known context.
unfortunately, due to context propagation, terms defined earlier on can "leak" into the naively merged subgraph.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
I.e., a Note or Article or whatever is saying that the author is NOT an actor on the same server host (example·com), but an actor over on the server host mastodon·social.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
ActivityPub outboxes are the new RSS / Atom / WebFeed.
You can just read from them to get a JSON feed of someone's posts.
I.e., you do NOT have to implement the full suite of Fediverse protocols, or Follow, or run your own server, or anything else to get someone's posts on the Fediverse — just read from their outbox.
As it is now, I think the 'discoverable' flag is broken.
And, I think the whole user-experience (UX) around the 'discoverable' flag is poor.
And, I think Fediverse software treating a 'false' value for 'discoverable' as "not discoverable" (rather than "not discoverable" or "no choice made") has hugely negative consequences for the user-experience (UX) of the Fediverse
With other conceptions, this lack of choice — this lack of setting a value — isn't as muddled.
With optional-types (which are also called "option-types" and "maybe-types") when something isn't assigned a value it is represented as 'nothing' / 'none'.
In relation-databases, this is represented as 'null'.
As it is now, I think the 'discoverable' flag is broken.
And, I think the whole user-experience (UX) around the 'discoverable' flag is poor.
And, I think Fediverse software treating a 'false' value for 'discoverable' as "not discoverable" (rather than "not discoverable" or "no choice made") has hugely negative consequences for the user-experience (UX) of the Fediverse
With other conceptions, this lack of choice — this lack of setting a value — isn't as muddled.
With optional-types (which are also called "option-types" and "maybe-types") when something isn't assigned a value it is represented as 'nothing' / 'none'.
In relation-databases, this is represented as 'null'.
You could create view-counts on posts, profiles, etc, using this.
Of course, there are privacy concerns with this.
And, also, what counts as a "view".
Although, I sometimes use a "Like" to indicate I viewed something. If a 'View' was something manual (such a pressing a button) that could be more semantically clean.
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
To me, it feels like the Activity Types should have been past-tense verbs, rather than present-tense verbs.
I.e.:
• "Accepted" rather than "Accept" • "Added" rather than "Add" • "Announced" rather than "Announce" • "Arrived" rather than "Arrive" • "Blocked" rather than "Block" • "Created" rather than "Create" • etc
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
If ActivityPub and ActivityStreams used acct-URI rather than HTTP-URL to identify users, then there would less problems with switching between different Fediverse software.
(Different Fediverse software represent users with different style HTTP-URLs — which creates the problem.)
What is the motivation for encouraging LitePub implementors to "supply a locally hosted version of the LitePub JSON-LD Context"?
Is it just for people using full-out JSON-LD parsers?
Won't this create problems for people using parsers that do NOT go download and interpret context-URIs? And instead just hard-code the vocabulary in their code?
ALT text detailsLitePub for ActivityPub Implementors
JSON-LD context
LitePub implementations are not required to use @context properties on their messages. A conformant ActivityPub implementation is required to process these messages with an injected @context of "https://www.w3.org/ns/activitystreams" as described in the ActivityStreams 2.0 Core Specification
However, the LitePub Core Vocabulary differs from the ActivityStreams 2.0 Vocabulary. It is suggested that LitePub implementations supply a locally hosted version of the LitePub JSON-LD Context as their @context. It may be useful to inject a local copy of the LitePub JSON-LD Context instead of the default ActivityStreams 2.0 context when a message is received without a @context as it defines the full LitePub Core Vocabulary in a way that is useful to JSON-LD processors.
Signatures
LitePub implementations MUST use HTTP Signatures to verify the authenticity of messages being delivered to or from peering nodes. The details surrounding the way HTTP Signatures are implemented in LitePub are discussed on the Overview page.
I'm looking for your opinions from the developers of the fediverse.
A common HTML web page can contain related links via the <link> tag. I would like to do the same for Activity Streams objects, for example:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://writings.hongminhee.org/ap/2024/12/a-year-with-the-fediverse.json",
"type": "Article",
"name": "A year with the fediverse",
"content": "2024 was truly a year where I was deeply immersed in the fediverse. …",
"url": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/",
"attachment": [
{
"type": "Link",
"rel": "alternate",
"hreflang": "ko",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ko-hang-kr.html",
"mediaType": "text/html"
},
{
"type": "Link",
"rel": "alternate",
"hreflang": "ja",
"href": "https://writings.hongminhee.org/2024/12/a-year-with-the-fediverse/index.ja.html",
"mediaType": "text/html"
}
]
}
Do you think this makes sense, and would it be appropriate to put Link objects in the attachment?
But because Mastodon only supports 8 of them (with only 2 of them being supported properly), there is "pressure" on other Fediverse software to restrict themselves to these 8.
Schon seit der ersten Version von Mastodon wollte ich eine Lobeshymne auf OStatus schreiben! Sowas wie "OStatus hat auch nach über 6 Jahren an Relevanz nicht verloren" oder "selbst nach 6 Jahren, setzen neue Plattformen mit Erfolg auf OStatus" oder "mein 6 Jahre altes OStatus WordPress Plugin funktioniert mit nur wenigen Anpassungen auch mit Mastodon"...
Das kann ich mir jetzt leider sparen. Eugen Rochko, der Gründer von Mastodon, schrieb schon 2018:
I can't wait until I can begin […]
Schon seit der ersten Version von Mastodon wollte ich eine Lobeshymne auf OStatus schreiben! Sowas wie „OStatus hat auch nach über 6 Jahren an Relevanz nicht verloren“ oder „selbst nach 6 Jahren, setzen neue Plattformen mit Erfolg auf OStatus“ oder „mein 6 Jahre altes OStatus WordPress Plugin funktioniert mit nur wenigen Anpassungen auch mit Mastodon„…
Das kann ich mir jetzt leider sparen. Eugen Rochko, der Gründer von Mastodon, schrieb schon 2018:
I can’t wait until I can begin removing OStatus-related code from Mastodon. I think GNU social is the last remaining fediverse project that hasn’t yet switched to ActivityPub?
…und der Pull-Request, der PubSubHubbub und Salmon ausbaut, wurde am 6. Juli ge-merged.
🙁
Wie geht’s weiter?
OStatus war wegweisend! Statt ein komplett neues Protokoll zu beschreiben, hat OStatus bestehende De-Facto-Standards in einer Spezifikation zusammen geführt. Für viele Plattformen, war es dadurch relativ einfach, OStatus einzusetzen, da sie in der Regel Teile der Spezifikation sowieso schon betrieben.
In den letzten Jahren habe ich aber gelernt, nicht zu sehr an Standards, Protokollen oder Technologien fest zu halten. OStatus wurde von ActivityPub eingeholt und aktuell ist GNU.social die einzige Plattform die ausschließlich auf OStatus setzt.
Zeit los zu lassen.
Ist ActivityPub die Zukunft?
Wie gerade schon geschrieben, ist es mir prinzipiell egal, welches Format sich durchsetzen wird. Mir ist nur wichtig dass sich ein Protokoll durchsetzt. Der Trend scheint zwar zu ActivityPub zu gehen… aber wer weiß?!?
Diaspora sieht bisher jedenfalls keinen Grund ActivityPub einzusetzen:
ActivityPub tries to work for everything and everyone. And because of that, they introduced a lot of flexibility and, sadly, a lot of ambiguity. Even though they tried, I found some reasons as for why we, as diaspora* developers, would not be able to build upon this new protocol without using heavily customized objects and activities.
und vor ein paar Wochen habe ich außerdem gelesen, dass HubZilla versucht sein Protokoll Zot zu standardisieren:
Join the efforts to standardize the Zot protocol, currently used in Hubzilla and Zap platforms. This is a community initiative to push Zot adoption for federated social web.