Cannot send Update activity to broadcast profile changes (Fedify v1/v2 + CJS Object export issue)

[rmdes]

Problem

When trying to broadcast an Update activity to followers after changing the bot profile (avatar, header, bio, etc.), the activity cannot be constructed or sent.

Root cause

1. Fedify v1's Object vocab class is broken in CJS exports — require("@fedify/fedify/vocab").Object is undefined because JavaScript's global Object shadows it in the CJS module.exports.

2. Update constructor's instanceof check fails — Even when loading the correct v1 vocab via createRequire, new Update({ object: actor }) throws "The object must be of type Object | URL" because the Service returned by ctx.getActor() fails the instanceof Object check (the Object class reference is broken).

3. clone() + sendActivity() also fails — Constructing an Update without object, then using clone({ objectIds: [actorUri] }) works for the initial construction, but sendActivity() internally calls clone() and signObject() which hit the same broken Object class reference.

What I tried

// Attempt 1: Direct construction — fails with "The object must be of type Object | URL"
const actor = await ctx.getActor(username);
const update = new Update({ actor: actorUri, object: actor });

// Attempt 2: Clone with objectIds — fails inside sendActivity's signObject
const update = new Update({ actor: actorUri });
const withObject = update.clone({ objectIds: [actorUri] });
await ctx.sendActivity({ identifier: username }, "followers", withObject);

Context

• Botkit 0.3.1 depends on @fedify/fedify@^1.8.15 (resolves to 1.10.5)
• My project also has @fedify/fedify@2.1.1 installed (via @fedify/redis)
• The dual-package situation means I can't import Update from v2 either (v2's Update rejects v1 Service objects)
• The code runs inside a SvelteKit server (Vite-bundled), with the bot code imported from src/bot/index.ts

Expected behavior

Calling ctx.sendActivity() with an Update activity containing the bot's actor should work, allowing profile changes to be broadcast to followers (as Mastodon and other implementations do).

Workaround

Profile changes propagate naturally when remote instances re-fetch the actor on the next post. But this means changes like avatar/header updates aren't visible to followers until a new diff is posted.

Possible fix

Upgrading Botkit to Fedify v2 would resolve the version mismatch. Alternatively, the CJS export of the Object class in v1 could be fixed (e.g., by renaming it to avoid collision with the global Object).

Repo

https://github.com/rmdes/newsdiff

[dahlia]

I think this can be addressed in BotKit by adding a higher-level API for this use case, rather than requiring users to construct and send a raw Update activity themselves.

Something like session.republishProfile() seems like a good fit here. The method could resolve the bot's current actor representation from the session context and broadcast an Update to followers, so user code only needs to express the intent of "my profile changed; republish it" instead of dealing with low-level Fedify vocabulary objects and recipient handling directly.

The Fedify-side CommonJS problem should still be tracked separately, since it affects the lower-level Object/Update path in some environments. I opened fedify-dev/fedify#651 for that part.

But even if the upstream issue is fixed, I still think BotKit would benefit from a dedicated API here, because this is really an actor/profile republishing use case, not a generic “manually build ActivityPub activities” use case.

If this direction makes sense, I think republishProfile() is a clearer API name than something more transport-oriented like broadcastActorUpdate(). An automatic “republish on startup if the actor profile changed” feature could also be considered later, but I would treat that as a separate enhancement on top of a smaller explicit API first.

[rmdes]

Thanks for the thoughtful response! session.republishProfile() is exactly the API we'd want — clean, intent-driven, no need to deal with vocabulary objects.

For now we're working around it by skipping the broadcast entirely:

// NOTE: Broadcasting an Update activity to followers is blocked by a Fedify v1/v2
// version mismatch in Botkit. Profile changes propagate on next post.
// Will be replaced by session.republishProfile() when available.
console.log('Bot profile reloaded from disk (profile changes propagate on next post)');

Happy to test a PR when the API lands. The automatic "republish on startup if changed" enhancement would be great too — our use case is a bot profile editor page where the admin uploads a new avatar/header and expects followers to see it without waiting for the next post.

[dahlia]

Fixed in v0.4.0.

[rmdes]

Just upgraded to Botkit 0.4.0 session.republishProfile() works perfectly.

The upgrade was smooth. The only breaking change that affected us was parseSemVer() removal (trivial fix plain string instead). The Fedify v1/v2 dual-package issue is completely gone now that Botkit uses Fedify 2.x directly.

One thing we ran into: the bot HTTP server was holding a stale reference to the old bot's fetch function. After reloadBotProfile() recreates the bot, the running HTTP server was still using the initial bot instance to serve actor requests. We fixed it by calling getBot().fetch(request) dynamically instead of capturing bot.fetch at startup. This might be worth mentioning in the docs if others hit it.

We also added cache-busting query params (?v={timestamp}) to avatar/header URLs on every profile save, since federated instances cache images by URL and won't re-fetch without a URL change even after receiving an Update activity.

Thanks for the fast turnaround on this from issue to shipped API in one release. The PostgreSQL repository and remote follow button are great additions too.