Skip to main content

"The inbox stream contains all activities received by the actor." (#ActivityPub Rec). However, AP/AS2 collections (including "special" ones like Inbox, Outbox, Followers, etc.) do not contain Objects or Activities. They contain URI *references*. That's why one Create/Note can be referenced by many inboxes. It may look like Collections contain Objects because of typical server JSON-LD serialization, but don't be fooled. It makes a difference for data lifecycle management and storage models.
#ActivityPub
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •
collections can contain IDs or object representations.
in reply to Evan Prodromou

Evan Prodromou
Evan Prodromou
• •
but yes, the definitive version of an object only lives in one place. All others are copies.
in reply to Evan Prodromou

Steve Bate
Steve Bate
• •
@evan How does work in RDF? Again, I'm talking about the underlying model, not the way it is serialized to JSON-LD for network communication. I'm also not discussing local caching/copying of remote AP/AS2 Objects (a different, but interesting topic).
@Evan Prodromou
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •
so, I think you have a broken idea of the primacy of RDF in Activity Streams 2.0. We literally never talked about that lens on the format when creating it. The origin in AS1 is pure JSON. Whatever the Turtle representation of a Collection is, it is entirely accidental and unintended.
in reply to Evan Prodromou

Steve Bate
Steve Bate
• •
@evan I see *numerous* discussions about RDF in the transcripts from AS2 SocialWG meetings c. 2014-2015 and I see at least one tracked issue that references the discussions. Yes, AS1 used JSON. However, AS2 uses JSON-LD. Per the JSON-LD spec, "a JSON-LD document is both an RDF document and a JSON document and correspondingly represents an instance of an RDF data model." Based on that, isn't AS2 (and therefore AP) data literally an RDF data model? 🤔 https://www.w3.org/Social/track/issues/21

ISSUE-21: Role of JSON-LD and RDF - Social Web Working Group Tracker

www.w3.org
@Evan Prodromou
in reply to Evan Prodromou

Evan Prodromou
Evan Prodromou
• •

the faction that was insistent on using as2 as rdf split off and became solid.

you can use as2 as rdf, and there are many advantages, but the format was designed to work as json first, jsonld second, and rdf last. not the other way around.

in reply to Evan Prodromou

Evan Prodromou
Evan Prodromou
• •

if you enjoy spec archaeology, you might like looking at the original draft rfcs that @jasnell did in 2014 before as2 came to w3c as part of the opensocial merger. you can see as the revisions progress how the problem of extensibility was handled. james started with urls as properties, then used a subset of jsonld to make it work.

https://datatracker.ietf.org/doc/html/draft-snell-activitystreams-00

JSON Activity Streams 2.0

This specification details a model for representing potential and completed activities using the JSON format.
IETF Datatracker
@James M Snell
in reply to jonny (good kind)

Steve Bate
Steve Bate
• •
@jonny @evan Very true for RDF, in general. However, in an ActivityPub context (at least, as specified) identity and location are somewhat tightly coupled. Although not AP per se, some aspects of the typical authorization implementations also rely on it. There are grassroots efforts with the goal of separating identity and location in AP, but it's still in the early stages.
@Evan Prodromou @jonny (good kind)
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •
@jonny you can't separate id and location in AP. It's a requirement. Every id has to be dereferenceable. That is a feature, not a bug.
@jonny (good kind)
in reply to Evan Prodromou

naturzukunft
naturzukunft
• •

@evan @jonny

Hm, id is the subject of the tripes. Location is an url. but between there can be a service, that is doning whatever. my subjects are <urn:rdfpub/df7815c3-5307-45af-8841-d94d423ea325/582b0148-bace-46b5-8a99-423e7ef5da9c>

And the http endpoint therefore is e.g. https://rdfpub.org/df7815c3-5307-45af-8841-d94d423ea325/582b0148-bace-46b5-8a99-423e7ef5da9c>

I know what you mean, but thats mor the feeling, that the user has. the technical realisation/internal representation may differ.

@Evan Prodromou @jonny (good kind)
in reply to Evan Prodromou

silverpill
silverpill
• •
'ap' URLs in FEP-ef61 are dereferenceable. Just like 'https' URLs, they are locations, but of a different kind. Instead of domain name system the naming authority is a cryptographic key.

fep/fep/ef61/fep-ef61.md at main

fep - Fediverse Enhancement Proposals
Codeberg.org
in reply to silverpill

Evan Prodromou
Evan Prodromou
• •
@silverpill @jonny thats a very misleading protocol name and identifier; you should use a different one.
@jonny (good kind) @silverpill
in reply to Evan Prodromou

silverpill
silverpill
• •
I can't think of a better name. This is a protocol for retrieving self-authenticating ActivityPub objects, 'ap' seems very appropriate.
in reply to silverpill

Evan Prodromou
Evan Prodromou
• •
@silverpill @jonny youre implying that this is the standard activitypub way to retrieve objects, which it is not. please change the name.
@jonny (good kind) @silverpill
in reply to Evan Prodromou

silverpill
silverpill
• •

Do you have any suggestions?

'ap' URLs are used by at least two projects, so we can't change the URL scheme easily, but I can add a note to the FEP saying that recommended scheme may change in the future.

in reply to silverpill

Evan Prodromou
Evan Prodromou
• •

@silverpill @jonny
```
evanp@Evans-MacBook-Pro mastodon % grep "^a" /usr/share/dict/words | shuf -n 1
astroglia
evanp@Evans-MacBook-Pro mastodon % grep "^p" /usr/share/dict/words | shuf -n 1
parbuckle
```

Astroglia Parbuckle.

@jonny (good kind) @silverpill
Unknown parent

Evan Prodromou
Evan Prodromou
• •
@naturzukunft that is part of the problem domain. John was removed from the cc list specifically because the author wanted to withdraw access.
@naturzukunft
Unknown parent

Evan Prodromou
Evan Prodromou
• •
and yet it works literally millions of times per day.
Unknown parent

naturzukunft
naturzukunft
• •
If there is exactly one object, then John no longer has access to the object after the update, or how else should I solve the access management. It is also possible that the object has changes after the update that John should not see.
in reply to naturzukunft

Steve Bate
Steve Bate
• •
@naturzukunft@mastodon.socia Yes, I think the Update part of ActivityPub is effectively broken and should be fixed someday. That said, I understand why it wasn't covered well back then. It's a very complicated topic and they seemed to want to downplay the AP/AS2 RDF foundations. Fortunately, there are ways implementations can "work around" the issues.
in reply to Steve Bate

naturzukunft
naturzukunft
• •
“That's why one Create/Note can be referenced by many inboxes”
Theoretically, I agree with you. But that's up to the implementation. I'm not yet sure how I'm going to solve this. But at the moment, each actor has its own RDF “database”. That gives me a more secure feeling with SPARQL queries and export or migration are much easier to implement.
At the moment I also have a memory for the public actor. How I solve this with the shared inbox remains to be seen.
in reply to Evan Prodromou

Steve Bate
Steve Bate
• •
@evan Yes, I acknowledged there are ways to work around it, some more "elegant" than others. Some servers, like Mastodon, don't have an inbox collection and don't store Activities (like old Update activities that would be effectively mutated by new ones when an Object is modified). They effectively just store the Objects and overwrite the data when the Objects are updated (and then synthesize new Create Activities on-demand for the pseudo-outbox).
@Evan Prodromou
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •
so you cant see the actual delta when fetching an `Update`? i agree, thats probably useful for tracking changes. but its not broken.
in reply to Evan Prodromou

Steve Bate
Steve Bate
• •
@evan To be clear, I'm not saying Mastodon per se is broken wrt Updates. I'm saying change tracking is problematic in the AP recommendation. An Object URI will always reference the latest state of the Object, not the previous states for previous Updates (all referring to the same `object` URI). The Update could have had the changes as the Activity `object` and the target URI to update as, well, the `target`. Then the history of changes could have been preserved.
@Evan Prodromou
in reply to Evan Prodromou

naturzukunft
naturzukunft
• •

@evan
I take a very critical view of this!
1. John writes a note “Russia has started the war”
2. mike likes john's note
3. John changes the note “Ukraine has started the war”
4. now Mike likes a note that he may never see and that he even thinks is wrong.

This is my understanding of the AP update process at the moment

@Evan Prodromou
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •
not backwards compatible. add a `delta` or `patch` property to the `Update` activity if you want to remember the changes.
in reply to Steve Bate

Evan Prodromou
Evan Prodromou
• •

i think a better path would be to define a new activity type in an extension, like `Patch`. it could use the semantics you describe, and perhaps also support versioning (apply these changes to this version of an object, resulting in this next version). if it becomes popular, it can be added to as2.

https://swicg.github.io/extensions-policy/

Process for Including Extensions in Activity Streams 2.0

swicg.github.io
in reply to naturzukunft

Evan Prodromou
Evan Prodromou
• •
@naturzukunft an astute observer can tell that john liked the object before the change. all the timestamps are there.
@naturzukunft
in reply to Evan Prodromou

naturzukunft
naturzukunft
• •
also in the clients such as mastadon ?
blablabla
@Evan Prodromou
This entry was edited (1 month ago)
Unknown parent

Evan Prodromou
Evan Prodromou
• •

@mro @naturzukunft well, people don't like software that keeps them from doing simple, commonsense things for dogmatic, exceptional reasons.

A visible edit history gives the benefits you're going for without forbidding typo fixes.

@naturzukunft @Marcus Rohrmoser 🌻
in reply to naturzukunft

Marcus Rohrmoser 🌻
Marcus Rohrmoser 🌻
• •

@naturzukunft @evan Yes. https://Seppo.Social may offer no such update. Delete yes, but update, no. For the mentioned reason and others.

Btw. rewriting the past is what Winston Smith did for a living in Orwell's 1984.

Weiterleitung

Client-side redirect to ./about/.
seppo.social
@Evan Prodromou @naturzukunft
in reply to Evan Prodromou

smallcircles (Humanity Now 🕊)
smallcircles (Humanity Now 🕊)
• •

@evan
FYI and as an aside.. Patch exists in #ForgeFed: https://forgefed.org/spec/#patch

(with the spec modeling a "forge" application, in which parts might be more reusable extensions, in this case e.g. "revision control")

ForgeFed

forgefed.org
#forgefed @Evan Prodromou
in reply to Evan Prodromou

naturzukunft
naturzukunft
• •
@evan
A few days ago I read the post
“#ForgeJo, #Gitea and #GitLab are all looking at federation via ActivityPub”. I'm curious to see how they solve the update problem when it comes to issues and MergeRequest.
#gitlab #Gitea #forgejo @Evan Prodromou
⇧