ActivityPub - How to Send an
🔗 **Source:** [ActivityPub - How to Send an](https://shkspr.mobi/blog/2026/09/activitypub-how-to-send-an-updated-user-profile-to-mastodon-and-the-fediverse/)
> [!note]+ Document Notes
> tags: [activitypub, fediverse, mastodon, decentralized-social, activitybot]
> author: Terence Eden
> source: Terence Eden’s Blog (shkspr.mobi)
> reference: https://shkspr.mobi/blog/2026/09/activitypub-how-to-send-an-updated-user-profile-to-mastodon-and-the-fediverse/
> date created: 2026-09-12 08:40
>
> > [!info] Generated analysis — not the author's words. Sections below are machine-written
> > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author.
> > Do not quote or attribute any other line to the named author.
>
> # 🏷️ Title: ActivityPub - How to send an updated user profile to Mastodon and the Fediverse
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Terence Eden's review of Evan Prodromou's *ActivityPub* (the source of the quoted definition): https://shkspr.mobi/blog/2026/09/book-review-activitypub-by-evan-prodromou/
- ActivityBot, the NLnet-funded project this post came out of: https://gitlab.com/edent/activity-bot
- NLnet NGI0 project page for ActivityBot: https://nlnet.nl/project/ActivityBot/
- ActivityPub W3C Recommendation (the `Update` activity is §6.6 of the spec, "Update Activity"): https://www.w3.org/TR/activitypub/
- Activity Streams 2.0 Vocabulary, `Update`: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-update
## 📝 Summary
- **What happened.** Terence Eden, building his ActivityBot under an NLnet NGI0 grant, hit a practical gap: after changing an ActivityPub account's name or description on his own server, nothing on Mastodon reflected it. The post is a 350-word how-to for the one message that fixes that — an `Update` activity whose `object` is the *whole new actor document*, delivered to every follower's inbox.
- **Why it matters.** The fediverse is push-based, not pull-based. Eden's key observation is that most Mastodon instances won't re-fetch your actor document on their own, so profile edits made on a custom server are invisible until the server announces them. Anyone writing a small ActivityPub implementation (a bot, a blog, a WordPress site with a federating plugin) needs this or their profile silently goes stale on every remote instance.
- **Key stakeholders.** Independent implementers of ActivityPub servers and bots; Mastodon and other fediverse software as receivers; NLnet as funder; Evan Prodromou's book as the reference that unlocked the answer.
- **Risks and tradeoffs.** The post shows a minimal `Update` and says outright that a real one carries more (inbox, public keys, avatar). It doesn't cover signing, delivery to shared inboxes, or what other software (Misskey, Pleroma, Lemmy) does with the message — "Mastodon immediately reflected the changes" is a single-implementation result. The example JSON as captured by Reader lost its outer keys and the source itself has a missing comma after `"type": "Update"`, so copying it verbatim won't parse.
- **Bottom line.** To propagate a profile change on the fediverse: send `{"type": "Update", "actor": <you>, "object": <your full new actor document>, "published": <time of the change>}` to your followers' inboxes. Mastodon applies it immediately.
## 📖 Main Content
The post solves one narrow problem with the ActivityPub protocol and does it in the order Eden discovered it.
**The problem.** ActivityPub servers learn about a remote actor by fetching its actor document (the JSON at the actor's `id` URL) once, typically when someone first follows or interacts. After that, most implementations cache it. Eden states the consequence plainly: Mastodon instances don't poll for profile changes, so an edit on your server stays local. This is the same design that makes the fediverse cheap to run — no server has to keep re-checking millions of remote profiles — and it means the burden of announcing change sits with the origin server.
**The clue.** Eden credits Evan Prodromou's *ActivityPub* book (Prodromou co-authored the W3C specification) for the answer, quoting its description of the `Update` activity: it updates the properties of the object named in its `object` property, and while the common case is content (`Note`, `Image`), actor types such as `Person` can also be updated. That last sentence is the whole trick — profile changes are just `Update` activities where the object happens to be the actor itself.
**The message.** The example is an Activity Streams 2.0 document: `@context` of `https://www.w3.org/ns/activitystreams`, an `actor` URL, an `id`, a `published` timestamp, `to` set to the Public collection, `type: "Update"`, and an `object` that is the actor document again — `@context` (now including the security vocabulary, because actor documents carry a public key), `id`, `name`, `summary`, and everything else an actor normally publishes. Eden's two operational notes are the ones a first implementer would miss: (1) send the *full* actor document, not a diff — inbox, keys, avatar and all; (2) the `published` value is the time of the change, not the account's creation time. He reports that once the message was delivered, Mastodon reflected the change immediately.
**What the post doesn't cover.** HTTP signatures (every delivery to a Mastodon inbox must be signed by the actor's key, or it is dropped); whether to deliver to each follower's personal inbox or to the instances' shared inboxes; how the `id` of the activity should be minted (the example uses a bare UUID, which most implementations would expect as a dereferenceable URL); and behaviour on non-Mastodon software. These are omissions, not errors — the post is explicit that it is a snippet from bot-building, and the "Thanks to NLnet" footer frames it as a work note.
**A capture defect and a source typo, for the record.** Reader's copy of the page lost the outer half of the JSON example (its `<pre>` holds only the nested `object`); the source page has all the keys. The source example itself is missing the comma after `"type" : "Update"`, so it is not valid JSON as printed. The full example from the source:
```json
{
"@context": "https://www.w3.org/ns/activitystreams",
"actor": "https://example.com/user",
"id": "6a9162a6-a8e5-ca0f-9c08-8e6b814acef8",
"published": "2026-08-31T12:34:56+01:00",
"to": "https://www.w3.org/ns/activitystreams#Public",
"type": "Update",
"object": {
"@context": ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"],
"id": "https://example.com/user",
"name": "My new name",
"summary": "A brand new description!"
}
}
```
(Comma after `"Update"` added; the ellipsis inside `object` stands for the rest of the actor document.)
### 🗒️ Notes
- **Framing:** the running joke (from "World's Number 1 Taylor Swift Fan" to "Nickleback Truther") is the only decoration; the rest is procedure.
- **The behavioural fact the post rests on:**
> [!quote]
> By default, most Mastodon instances won't periodically poll your account information just to see if you've updated it. So how does the information get from your server to your followers' servers?
- **The borrowed definition, quoted from Prodromou:**
> [!quote]
> The most common types of objects that can be updated are content objects, like Note or Image. Actor types (like Person) and Question activity types can also be updated.
- **The instruction:** craft an `Update` whose `object` is the *new* user information and send it to every follower's inbox.
- **Two constraints on the payload:**
> [!quote]
> Obviously the full user information is a bit more than that - it will include inbox details, public keys, avatars, etc. The published property in the Update activity should be when you changed your details - not when the account was created.
- **Observed result:**
> [!quote]
> Once that was sent, Mastodon immediately reflected the changes.
- **Provenance:** funded in part by Eden's NLnet NGI0 grant for ActivityBot; the post links the GitLab repo and the NLnet project page.
- **Scope signal:** "most Mastodon instances" and "Mastodon immediately reflected" — one receiving implementation tested, stated as such.
## 📚 References
- [Book review: ActivityPub by Evan Prodromou — Terence Eden](https://shkspr.mobi/blog/2026/09/book-review-activitypub-by-evan-prodromou/) — where the quoted definition comes from.
- [ActivityBot on GitLab](https://gitlab.com/edent/activity-bot) — the project the technique was built for.
- [NLnet: ActivityBot](https://nlnet.nl/project/ActivityBot/) — the grant.
- [ActivityPub, W3C Recommendation, §6.6 Update Activity](https://www.w3.org/TR/activitypub/#update-activity-outbox) — the normative text: the receiving server MUST update its copy of the object with the one supplied.
- [Activity Streams 2.0 Vocabulary — Update](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-update)
## 🗣️ Paraphrase
- Say you change your account's description on your ActivityPub server. How do other fediverse servers find out?
- They don't go looking. Mastodon instances won't poll your profile for changes, so your server has to tell them.
- Eden didn't find this obvious; the hint came from Prodromou's book: `Update` changes the properties of whatever its `object` names, and that object can be an actor like a `Person`, not only a post.
- So: build an `Update` activity whose `object` is the new actor document and deliver it to each follower's inbox.
- The example is a minimal Activity Streams document — actor, id, published, public addressing, type `Update`, and the new actor object with its name and summary.
- A real actor document is bigger (inbox, public keys, avatar); send all of it. Set `published` to the time of the change, not the account's birth.
- Once delivered, Mastodon showed the new profile at once.
- The work was part of an NLnet-funded bot project.
## 📰 Newsletter
**Your fediverse profile edit didn't go anywhere.** Terence Eden, mid-way through building ActivityBot on an NLnet grant, changed a profile description on his own ActivityPub server and watched Mastodon keep showing the old one. The fix he documents is one message: an `Update` activity whose object is your *entire* new actor document, pushed to every follower's inbox, with `published` set to the moment you made the change. Mastodon applies it immediately. If you're running or building anything that federates — including a WordPress site with the ActivityPub plugin — this is the mechanism that keeps your name, bio and avatar honest across the network. Bonus: the post is a good demonstration of reading the spec through Evan Prodromou's book rather than reverse-engineering Mastodon. [Read the post](https://shkspr.mobi/blog/2026/09/activitypub-how-to-send-an-updated-user-profile-to-mastodon-and-the-fediverse/) · [ActivityBot](https://gitlab.com/edent/activity-bot)
## ✅ Action Items
#### DevRel
- Developer advocacy: fold "profile edits are `Update` activities on the actor" into any ActivityPub 101 talk or demo; it is the single most common gap in toy implementations.
- Education: a 20-minute workshop module — change a bio on a test server, watch the remote instance not change, send the `Update`, watch it change.
- Developer experience: publish a copy-pasteable, *valid* `Update` example (the post's has a missing comma and a bare-UUID `id`) with signing notes alongside.
- Developer marketing: not applicable — a protocol how-to, not a product.
- Community management: not applicable.
- Internal/external/cross-project: share with the WordPress ActivityPub plugin maintainers as a check that profile changes on a site trigger an actor `Update`.
#### OSPO
- Policy & Governance: not applicable.
- License Compliance: not applicable — no code is redistributed.
- Security Management: any implementation of this needs HTTP-signature delivery; document that an unsigned `Update` to an actor is dropped by Mastodon.
- Software Inventory: note ActivityBot as an NLnet-funded reference implementation worth tracking.
- Developer Support: add "why doesn't my profile change show on Mastodon?" to an ActivityPub FAQ with this answer.
- Community Engagement: NLnet NGI0 funds small fediverse tooling; a candidate model for WordPress-adjacent federation work.
- Strategic Alignment: not applicable.
#### Community
- Maintainers: for anyone maintaining a federating WordPress plugin, verify actor `Update` on profile save.
- Contributors: a good "first federation issue" — reproduce the stale-profile behaviour on a test instance.
- Sponsors: not applicable.
- Ecosystem: interop testing across Mastodon, Misskey, Pleroma, Lemmy for actor updates.
#### WordPress
- Core: not applicable.
- Core Performance: not applicable.
- Core AI: not applicable.
- **Core Program Team:** not applicable.
- Mobile: not applicable.
- Playground: not applicable.
- Community: not applicable.
- Training: an ActivityPub lesson on Learn.WordPress.org could use this as the "push, not pull" example.
- Marketing: not applicable.
- Support: support answer for the ActivityPub plugin — "profile changes propagate via an Update activity; check that the site can sign outgoing requests."
- Design: not applicable.
- Documentation: not applicable to core; relevant to the ActivityPub plugin's docs.
- Photos: not applicable.
- TV: not applicable.
- Polyglots: not applicable.
- Accessibility: not applicable.
- Meta: not applicable.
- CLI: not applicable.
- Hosting: hosts blocking outbound signed requests break federation silently; a checklist item.
- Tide: not applicable.
- Openverse: not applicable.
- Themes: not applicable.
- Plugins: the ActivityPub plugin (Automattic-maintained) is the WordPress surface for this behaviour; confirm it sends actor `Update` on profile change.
#### The WPOCC
- Programs: not applicable.
- Projects: not applicable.
- Funding experiments: NLnet NGI0's small-grant model funded this work; a pattern worth citing.
### FAIR
- Technical independence: federation identity that survives profile edits is part of owning your presence; the `Update`-on-change rule is what keeps a self-hosted actor accurate.
- Policies and covenants: not applicable.
- Productized governance artifacts: not applicable.
## 🧪 Hypotheses
- H1: Sending an `Update` whose `object` is the full actor document causes Mastodon to refresh the cached profile immediately, without waiting for its periodic refetch.
- H2: Sending an `Update` whose `object` contains only the changed fields (a diff) causes Mastodon to overwrite the cached actor with an incomplete record, breaking display or delivery.
- H3: Mastodon rejects an actor `Update` whose HTTP signature is missing or does not match the actor's published key.
- H4: Other fediverse software (Misskey, Pleroma/Akkoma, Lemmy, GoToSocial) applies actor `Update` activities with the same immediacy as Mastodon.
- H5: Delivering the `Update` to instances' shared inboxes (one per instance) produces the same result as delivering to every follower's personal inbox, with fewer requests.
### 📊 Methodology
- Two test instances (Mastodon plus one other implementation), a minimal ActivityPub actor under your control with at least one follower on each.
- For H1/H2: change the actor's `summary`; send full-object and diff-object `Update`s in separate trials; read the remote profile via each instance's API and record the fields present.
- For H3: send the same `Update` unsigned, signed with the wrong key, and signed correctly; observe HTTP status and remote state.
- For H4/H5: repeat H1 across implementations and across personal-inbox vs shared-inbox delivery; log request counts and the time to visible change.
### ❓ Questions
- Does Mastodon ever refetch actor documents on its own, and on what schedule — is "won't periodically poll" strictly true or "won't poll often enough to matter"?
- What happens when the `Update` arrives before the follower's instance has ever fetched the actor?
- Should the activity `id` be a dereferenceable URL rather than a bare UUID, and does any implementation refuse the bare form?
- How does the WordPress ActivityPub plugin handle this today — on profile save, on a cron, or not at all?
### 🔮 Future Research
- A cross-implementation matrix of actor `Update` handling (fields honoured, signature requirements, shared-inbox behaviour).
- Whether `Update` on an actor should carry `updated` in the object as well as `published` on the activity, and which implementations read which.
- ActivityBot's own implementation as a reference: how it schedules profile updates and handles delivery failures.
### 💡 Implications
- Practice: any self-hosted ActivityPub identity needs an "on profile change, deliver actor `Update`" hook, or its remote representation rots.
- Policy: not applicable.
- Security: delivery must be signed; the post's silence on signing is the biggest thing a reader could trip over.
- Education: a clean illustration that the fediverse is push-based and that the spec (via Prodromou's book) answers questions Mastodon's behaviour alone would not.
- Funding: a small NLnet grant produced a reusable, documented finding — the kind of output the NGI0 model is meant to yield.
### 🧠 Learning Styles Assessment
- Reading level estimate: Flesch-Kincaid grade ≈ 9 (short sentences, one code block, protocol vocabulary assumed).
#### 👀 Visual learners
- Present: one JSON code block; the NLnet logo.
- Improve: a sequence diagram (origin server → follower inboxes → remote profile refresh) would make the push model obvious.
#### 🔊 Aural learners
- Present: nothing.
- Improve: a two-minute spoken walkthrough of the before/after would suit the anecdotal framing.
#### 🗣️ Verbal learners
- Present: the definition quoted from Prodromou; the "poll" vs "push" contrast in plain words.
- Improve: define `actor`, `object` and `inbox` inline for readers new to the vocabulary.
#### 🧩 Kinesthetic learners
- Present: a concrete payload to try.
- Improve: a checklist (change field → build `Update` → sign → deliver → verify) and a note on which curl or library call sends it.
#### 🧠 Logical learners
- Present: cause and effect are explicit (no polling, therefore push).
- Improve: a table of activity `type` × `object` type showing where actor updates sit.
#### 🧑🤝🧑 Social learners
- Present: comments on the blog.
- Improve: a pointer to where implementers compare notes (SocialHub, the ActivityPub spec repo).
#### 🧘♀️ Solitary learners
- Present: self-contained; can be reproduced alone with a test server.
- Improve: a link to a minimal test harness.
#### 🌿 Naturalistic learners
- Present: nothing.
- Improve: the "push only on change" model is a good example of network efficiency — no polling — worth a sentence.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: a single H1, an H2 for "Thanks to NLnet", paragraphs, a blockquote for the book excerpt, a code block; the NLnet image has alt text ("NLnet logo.").
- Improve: the JSON `<pre>` has no accessible name or caption; a preceding sentence ("Something like this:") is the only label.
#### Keyboard navigation
- Present: standard links; a "Copied JSON" copy control on the code block.
- Improve: the copy control is a clickable element with inline `onclick`; confirm it is a `<button>` reachable by keyboard.
#### Contrast and readability
- Present: plain text on a light theme; not measured here.
- Improve: verify the code block's syntax colours against WCAG 2.2 1.4.3.
#### Text resizing and reflow
- Present: single-column prose reflows; not measured at 200%.
- Improve: the code block should scroll horizontally rather than the page.
#### Media and captions
- Present: one image with alt text and a figcaption.
- Improve: not applicable — no audio or video.
#### Forms and interactions
- Present: a share control at the foot of the post.
- Improve: the share control uses `alert()` as feedback, which screen readers handle unevenly; a live region would be better.
#### Standards reference
- WCAG 2.2 AA: 1.1.1 (alt text present), 2.1.1 (verify copy/share controls are keyboard-operable), 4.1.2 (name/role on the copy control), 1.4.10 (reflow of the code block).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: the Taylor Swift / Nickelback joke is Anglo-American pop culture; the technical content is culture-neutral.
- Improve: not applicable for a 350-word protocol note.
#### Inclusive language
- Present: second person, no gendered terms, jargon (`actor`, `inbox`) used without definition.
- Improve: one-line definitions of `actor` and `object` would widen the audience.
#### Neurodiversity support
- Present: short paragraphs, one idea each, a single code block, the answer stated early ("Aha!").
- Improve: a summary line at the top would help skimmers.
#### Representation
- Present: one author, one cited author (Prodromou); both credited by name.
- Improve: not applicable.
#### Psychological safety
- Present: the author admits the answer "wasn't immediately obvious to me" — modelling not-knowing.
- Improve: not applicable.
### ✅ Logical Validity
#### Strong reasoning
- Causal chain is explicit and sound: remote servers don't poll → the origin must push → the spec's `Update` on an actor is the push → tested against Mastodon → it worked. Each link is either a stated observation or a quoted definition.
- The cited authority is the right one: Prodromou co-authored the ActivityPub specification, and the quoted definition matches the spec's own text on `Update`.
- The two operational caveats (send the full object; `published` is the change time) are stated as instructions, not inferences, and both match how the spec describes `Update` semantics (the supplied object replaces the stored one).
#### Fallacies
- **Hasty generalization (mild):** "Mastodon immediately reflected the changes" is one implementation on one occasion, offered as the confirmation. The post never claims more, so this is a scope limit rather than a fallacy proper; the fix is a sentence noting that other software was not tested.
- **Omitted premise:** the message only works if signed; the post presents delivery as if sending the JSON were sufficient. Not a reasoning error in what is said — an unstated precondition a reader could miss. Fix: one line on HTTP signatures.
- No other fallacies. The example's missing comma is a typo, not an argument.
#### Tone of voice
- Light, self-deprecating, practical: "Aha!", "Obviously the full user information is a bit more than that". Written as a lab note for other implementers, with a joke at the top and a funder credit at the bottom.
### 🛡️ DARVO Analysis
- Deny: not applicable — no accusation, dispute, or defence anywhere in the post.
- Attack: not applicable.
- Reverse victim/offender: not applicable.
- The framework does not apply to a first-person technical how-to with no adversary; recording that rather than forcing a reading.
## 🎯 Conclusion
- Profile changes on the fediverse propagate only when the origin server sends an `Update` activity whose `object` is the complete new actor document, with `published` set to the time of the change; Mastodon applies it immediately.
- Next steps for readers: implement the hook on profile save; sign the delivery; fix the missing comma before copying the example; test against at least one non-Mastodon implementation; if you run WordPress with the ActivityPub plugin, check whether it already does this.
## 🔄 Refactor Appendix — ActivityPub - How to send an updated user profile to Mastodon and the Fediverse
> Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4).
> Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't
> articulate in one line why a claim matters, drop it.
>
> Konik claim-header rules: present tense, declarative, ≤10 words when
> possible, searchable, unique, mirrors annotation focus if present.
>
> Atomicity: one declarative sentence per atom. "and"/"also" → split.
>
> Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms
### 📚 Literature Atoms (H3)
#### [H1] Fediverse profile changes propagate by push, not by polling
> [!quote] ID:rw_01m2ayyhaf4e20p6jf20tcdptx
> By default, most Mastodon instances won't periodically poll your account information just to see if you've updated it.
**Context & use**:
- Paragraph 2, the premise of the whole post.
- The design fact that makes the rest necessary; reusable whenever someone asks why a self-hosted profile looks stale elsewhere.
**Tags**: #xref #share
**Highlight**: [view highlight](https://read.readwise.io/read/01m2ayyhaf4e20p6jf20tcdptx)
<!-- atomicity: 1 idea ✓ -->
#### [H2] An actor Update carries the whole new actor document
> [!quote] ID:rw_01m2ayypp4qgr3p67fbjm9ztxr
> Obviously the full user information is a bit more than that - it will include inbox details, public keys, avatars, etc.
**Context & use**:
- Paragraph after the JSON example.
- The operational rule: `Update` replaces the stored object, so a partial object would replace a full one.
**Tags**: #xref
**Highlight**: [view highlight](https://read.readwise.io/read/01m2ayypp4qgr3p67fbjm9ztxr)
<!-- atomicity: 1 idea ✓ -->
#### [H3] Actor types can be the object of an Update
> [!quote] ID:rw_01m2ayysdcefxq8wdbzs77mafs
> Actor types (like Person) and Question activity types can also be updated.
**Context & use**:
- Quoted from Evan Prodromou's *ActivityPub* inside the post's blockquote; the sentence that unlocked the answer.
- The spec-level permission that profile edits are ordinary `Update` activities.
**Tags**: #xref
**Highlight**: [view highlight](https://read.readwise.io/read/01m2ayysdcefxq8wdbzs77mafs)
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] A Federated Identity Is Only As Current As Its Last Announcement
**Claim** (one sentence, Courtney's voice): In a push-based federation, your profile is whatever remote servers last heard, so every local change is invisible until you announce it.
**Evidence pointer**: [[#H1]], [[#H2]]
**Scope & conditions**: Holds for ActivityPub as implemented by Mastodon (no periodic actor refetch). Weakens where an implementation does refetch on a schedule or on every interaction; check before assuming staleness is permanent.
**Links** (≥1 with annotation):
- [[Trademarks Are the Only Asset a Fork Cannot Route Around]] — because contrasts on where identity lives: a name in a registry vs a document remote servers cache
- [[Trust Granted at Admission Must Be Re-Verified at Every Update]] — because extends: the `Update` is exactly the re-verification moment, and it must be signed to be trusted
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Does the WordPress ActivityPub plugin send an actor `Update` on profile save, or does a changed bio go stale on Mastodon? — https://wordpress.org/plugins/activitypub/ #fleeting #inbox
- [F2] The post's example JSON is missing a comma after `"type": "Update"`; Reader's capture also dropped the outer keys — worth a comment on the post. #fleeting #inbox
### → Things 3 (max 2 actions)
- [ ] Test whether courtneyr.dev's ActivityPub plugin pushes an actor Update after a profile edit — check a follower instance #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/ActivityPub - How to Send an.md|ActivityPub - How to Send an by Terence Eden]]
## Highlights
- By default, most Mastodon instances won't periodically poll your account information just to see if you've updated it. So how does the information get from your server to your followers' servers? ([View Highlight](https://read.readwise.io/read/01m2ayyhaf4e20p6jf20tcdptx))
- Note: The premise: the fediverse is push-based. Remote servers cache your actor document and don't refetch it, so a profile edit stays invisible until your server announces it.
- Tags: atom/literature/h1
- The most common types of objects that can be updated are content objects, like Note or Image. Actor types (like Person) and Question activity types can also be updated. ([View Highlight](https://read.readwise.io/read/01m2ayysdcefxq8wdbzs77mafs))
- Note: Quoted from Evan Prodromou's ActivityPub book (Prodromou co-authored the spec): the sentence that makes profile edits ordinary Update activities.
- Tags: atom/literature/h3
- You need to craft an `Update` message which has as its object the *new* user information. That needs to be sent to the inbox of all your followers. ([View Highlight](https://read.readwise.io/read/01m2ayym05f22k541tvnety0xw))
- Note: The fix in one sentence: an Update activity whose object is the new actor document, delivered to every follower's inbox. Unstated precondition: the delivery must be HTTP-signed or Mastodon drops it.
- Tags: action/h2, atom/literature/h1
- Obviously the *full* user information is a bit more than that - it will include inbox details, public keys, avatars, etc. The `published` property in the Update activity should be when you changed your details - not when the account was created. ([View Highlight](https://read.readwise.io/read/01m2ayypp4qgr3p67fbjm9ztxr))
- Note: Two rules a first implementer misses: send the whole actor document (Update replaces, it doesn't merge), and stamp published with the time of the change.
- Tags: atom/literature/h2