Decide age, catalog access, takedown contacts, chat retention and server rendering

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/design.md

@@ -103,13 +103,14 @@ age, not verified) and `tagline`.
 
 ## Age (**Decided**: IMVU's verification)
 
-- Adult content requires the **IMVU account in use** to be age verified (`is_ageverified`), checked by the hub
+- Adult content requires the **IMVU account in use** to be age verified (`is_ageverified`) or to have Access Pass
+  (`is_ap`; **Decided**: it counts), checked by the hub
   itself (never reported by the proxy, which anyone can change): at linking and at most daily after, cached.
   Revocations show up at the next check.
 - Per IMVU account, not per person, so one verified account doesn't unlock others a minor might use.
 - Enforced at three points: catalogs (adult files need an adult token), the hub (adult items left out of room
   channels for viewers who aren't verified and opted in), and the viewer's proxy.
-- Self-reported `is_adult` doesn't count. Whether `is_ap` counts is open.
+- Self-reported `is_adult` doesn't count.
 
 ## Products and catalogs
 
@@ -140,6 +141,23 @@ age, not verified) and `tagline`.
   token.
 - Operators can build their own branded site on the public API.
 
+### Joining the hub and access (**Decided**)
+
+- **Any catalog can ask to join** the hub. It's hidden until a hub moderator approves it.
+- To join, a catalog must give **its own takedown and legal contact**. It stores the files, so the hub forwards
+  takedown notices and reports about its products to that contact (and can still block a product network-wide).
+- Two settings per catalog:
+  - **Visibility**: *public* (listed in the hub's directory and search) or *private* (not listed; found through an
+    invitation or link).
+  - **Membership**: *open* (any hub user can use it), *approval* (users ask, the catalog's operators approve) or
+    *invite only*.
+
+  Any combination works: a public catalog can still require approval; a private one can be open to anyone who has
+  the link.
+- **Seeing versus wearing** (proposed): membership is needed to get and wear a catalog's products; anyone can *see*
+  them on someone else (subject to age settings), or outfits would break depending on who's looking. A catalog can
+  choose members-only viewing, at the cost of members' items showing as defaults to everyone else.
+
 ## Outfits
 
 1. The user puts on a community item. The client shows it (proxy answers for it); the patch sends IMVU the outfit
@@ -160,7 +178,8 @@ is per person, shared across their accounts.
   bans, chat, seats, presence. The proxy routes that room's IMQ traffic to the hub, which speaks the subset of
   IMQ the client needs (subscribe, state changes, mounts, messages) and the room-joining XML-RPC calls, so the
   client treats it as an ordinary room. Needs our own definitions of those messages, written from observation.
-- **Chat retention**: not stored by default; kept briefly only when someone reports it.
+- **Chat retention** (**Decided**): not stored by default. When someone reports a conversation, the recent messages
+  around the report are kept as evidence for 30 days, then deleted.
 - Room shells and furniture are ordinary products.
 
 ## Presence and badge (**Decided**: both opt-in, per IMVU account)
@@ -211,8 +230,9 @@ One Go program in modules (split into services only if load requires it):
 - **Moderation**: reports, actions, blocklist, audit log.
 - **Website and console** (**Decided**: in this repo): browse catalogs, products, creators, rooms, news; manage
   accounts (links, privacy, data export and deletion); catalog operators' screens; moderation console.
-  Proposed: server-rendered HTML from Go (templ) with htmx, built into the program: fast, cacheable at Cloudflare,
-  indexable, no JS build.
+  **Decided**: server-rendered. Proposed: templ (Go templates) and htmx, built into the program: fast, cacheable at
+  Cloudflare, indexable, no JS build. How it looks comes from its CSS (a small design system of our own), not from
+  rendering on the server; small scripts where a page needs richer interaction (image galleries, drag and drop).
 
 ### Data (sketch)
 
@@ -276,9 +296,7 @@ The proxy streams and adds no waiting.
 
 ## Open questions
 
-- Does `is_ap` (Access Pass) count as age verified?
-- Website: templ and htmx, as proposed?
-- Catalog listing: open registration with review, or invitation at first?
-- The takedown contact and legal entity for the hub.
-- Hosted rooms: how much of IMQ the client needs for a room (to be worked out from observation).
-- How long reported chat is kept.
+- Seeing versus wearing private catalogs' products (proposal above).
+- The takedown contact and legal entity for the hub itself.
+- Hosted rooms: how much of IMQ and the room-joining calls the client needs (being investigated; see
+  docs/imq-rooms.md when it exists).