bf9787e56a
Gap analysis of docs/architecture.md against openspec/ and docs/ideas/ found the envisioned-but-uncaptured remainder. This commit captures it: New OpenSpec change (validated): - route-federation — the collaboration half of the federation vision: routes as dereferenceable trails:Route objects, Create/Update fan-out, Invite/Accept collaboration mirroring (arch decision #2), cross-instance Planner edits via HTTP-Signature-requested scoped tokens (decisions #3/#12), mirror sync healing (#16). Depends on social-federation §6 + route-sharing; carries the 2026-06-07 soak lessons as design constraints. New docs/ideas/ explorations: - instance-administration — registration toggle, suspend/ban, federation blocklists, reports (moderation now gates the federated comments idea) - social-interactions — local likes + comments (don't exist even locally; the foundation federated kudos/comments attach to) - activity-participants — group tagging with confirm/decline + federated mentions (the participants jsonb column is an untyped stub) - multi-day-collections — architecture open question #1, directions evaluated architecture.md cleanup: - Mastodon-compat section annotated with shipped/captured state + the live-soak interop lessons (attachment arrays, tombstones, 10s timeout, no backfill) - api.trails.cool removed (contradicted resolved decision #18) - Phase 1 ticked (shipped); Phase 2/3 items annotated with where each is tracked; specs/ → openspec/, activity.* → journal.*, cx21 → cx23 - brouter-web open question marked resolved-in-practice; new section pointing to where the unshipped vision is tracked Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
# Local likes & comments
|
|
|
|
Pre-spec exploration. The architecture's Journal feature list has
|
|
"Social: Following, likes, comments" — follows shipped
|
|
(`social-follows`), likes and comments don't exist **even between local
|
|
users**. The federated halves are sketched separately in
|
|
`fediverse-enhancements.md` (kudos = inbound Like/Announce, comments =
|
|
inbound replies); this idea is the local foundation those would attach
|
|
to.
|
|
|
|
## Scope sketch
|
|
|
|
**Likes (kudos)**
|
|
- One per (user, activity); toggleable; count on activity cards + detail
|
|
- Notification to the activity owner (`notifications` spec has the
|
|
pattern; new type `activity_liked`)
|
|
- Storage: `journal.likes (user_id, activity_id, created_at)` or a
|
|
generalized reactions table if we ever want more than ❤️ — start
|
|
with likes only (simplicity principle)
|
|
- Federation hook-in later: inbound Mastodon `Like` increments the same
|
|
counter with `remote_actor_iri` instead of `user_id` (same
|
|
exactly-one-of pattern as `follows.follower_id`/`follower_actor_iri`)
|
|
|
|
**Comments**
|
|
- Flat list on activities first (no threading — Mastodon-reply
|
|
interop pushes toward flat anyway); plain text → maybe limited
|
|
markdown later
|
|
- Owner can delete comments on their activities; commenter can delete
|
|
their own
|
|
- Notification type `activity_commented`
|
|
- Federation hook-in later: inbound replies (`inReplyTo`) land in the
|
|
same table with remote attribution; outbound, local comments on a
|
|
federated activity would need to federate back as replies
|
|
|
|
## Constraints & notes
|
|
|
|
- Visibility: liking/commenting requires the activity to be visible to
|
|
you — public activities only for non-owners today; revisit when
|
|
followers-only content lands (§7/§8 of social-federation).
|
|
- The `activities.owner_id` NOT NULL open question (design.md of
|
|
social-federation) applies to remote comment authors the same way —
|
|
decide once.
|
|
- Decide whether routes also get likes/comments or activities only.
|
|
The architecture says activities; start there.
|
|
- Moderation precedes federated comments (see
|
|
`instance-administration.md`) but NOT local comments — local users
|
|
are accountable accounts on your own instance.
|