RFC / speculative: what could ActivityPub (fediverse) integration look like for PlaceCal?

[kimadactyl]

Summary

Thinking out loud about what it would mean for PlaceCal to speak ActivityPub, so that partners and places become things you can follow directly from the open social web (Mastodon, Mobilizon, and friends). This is speculative, there's no commitment or timeline, and the point of the issue is to capture the reasoning (including the reasons it might be a bad idea) so it isn't lost. Thoughts very welcome.

Why this is interesting for PlaceCal specifically

PlaceCal's data model already lines up almost 1:1 with ActivityPub's vocabulary, which is unusual and makes this cheaper than it would be for most apps:

PlaceCal	ActivityPub
Partner (org)	Organization / Group actor
Place / Neighbourhood	Group / Service actor
Event	Event object
Article (news)	Article / Note

The genuinely distinctive idea in here: the fediverse is overwhelmingly built around people broadcasting. PlaceCal could make place a first-class thing you follow. "Follow your neighbourhood" is a primitive the fediverse doesn't really have today, and it fits PlaceCal's direction as interoperable commons infrastructure rather than a walled directory.

What it could look like (rough and phased)

1. Partner actors. @some-org@placecal.org, followable, their events and news federate out as they're published. Low volume, the clean atom to start with. A group with only a calendar feed gets a fediverse presence for free.
2. Place / neighbourhood actors. Follow an area. This aggregates many partners, so it's a firehose risk. The likely answer is digest-style posting (one "this week in Hulme" roundup with a link) rather than one post per event.
3. Ingesting fediverse event sources (Mobilizon, Gancio) as another calendar source type. Noted for completeness but deferred, there's no demand pulling for it yet.

The honest caveats (why this is "experimental", not a headline feature)

• Mastodon has no native event UI. It converts an AP Event into a plain status post, and it doesn't process Update on events, so a time change or cancellation won't propagate to people who saw the original.
• A timeline shows you an event when it's posted, not when it's happening. That's discovery, not a reminder. For "know it's on tonight", an ICS calendar subscription still wins, and PlaceCal already does that. ActivityPub adds reach, not reminders.
• Events render properly as events only in event-native clients (Mobilizon, Gancio, Bonfire, Gathio), which are a smaller audience than Mastodon.
• So the realistic framing is: PlaceCal becomes a proper fediverse event source and gives orgs and places a followable identity, discovery, and a backlink to the real event page. It is not "manage your event-going inside Mastodon".

Technical sketch

fedipub (formerly Federails) is a Rails engine that provides the ActivityPub plumbing (webfinger discovery, actors, inbox/outbox, followers collections, HTTP signatures). PlaceCal is a Rails app, so this drops in rather than needing a separate service. Declaring a model federated looks roughly like:

class Partner < ApplicationRecord
  include Fedipub::ActorEntity
  acts_as_fedipub_actor username_field: :slug,
                        name_field: :name,
                        profile_url_method: :partner_url
end

class Event < ApplicationRecord
  include Fedipub::DataEntity
  acts_as_fedipub_data handles: 'Event'
end

Two things need verifying in fedipub's source before anyone commits to this, and they're the whole ballgame:

1. Does handles: 'Event' serialise real Event properties (startTime, endTime, location / Place), or does it just stamp the type as "Event" and emit a generic object? This decides whether Mobilizon/Gancio read our events as events at all.
2. How a data object binds to the actor whose outbox and followers it publishes through (we'd need Event belongs-to Partner-actor, so a follower of one org gets that org's events and nobody else's).

Operational realities worth thinking about early: a single canonical actor host across our multi-tenant sites and custom domains; keypairs and rotation; mapping event re-import churn to Create/Update/Delete without spamming followers on every re-import; and the fact that even follow-only federation opens an inbox, which is some moderation surface.

Explicitly out of scope (for now)

• Running a general-purpose social server. That's a different project.
• Two-way social interaction (replies or DMs landing in PlaceCal).
• Inbound ingestion of fediverse events (deferred until there's demand).

Open questions

• Is "follow a place" actually useful to you, or is per-org following the real want?
• Which fediverse clients matter to your community?
• Does anyone know whether fedipub serialises real Event objects today?
• What digest cadence would make a neighbourhood actor a good citizen rather than spam?

Status

Speculative RFC. No timeline, no commitment, mostly here so the thinking is written down. If you're a Rails dev who finds this fun, or a fediverse person with strong opinions, comments are the point of the issue.