trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trails/docs/ideas/social-interactions.md
Ullrich Schäfer bf9787e56a docs: capture remaining architecture vision; draft route-federation change 
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>
2026-06-07 10:31:50 +02:00

2.1 KiB
Raw Blame History

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.