Make the landing page a personal front door: address, doorbell and letterbox

[asim]

Product direction from the owner: the landing page is the front door. A visitor needs a way to contact you, notify you, or leave something interesting. A personal assistant should manage that threshold.

Related: #1585, #1573 (navigation), #1570 (one assistant), #1485 (channel identity), #1575 (quiet delivery), #1571 (action authority).

The product model

Element	Visitor intent	Product behaviour
Address	Reach this person/home again	A stable web URL and reachable email address. On a personal domain this could be home@domain; on a shared host use the account's existing address. Clarify who receives it.
Letterbox	Leave a message, link, file or invitation	A short submission form plus ordinary email delivery. Store once in the owner's Inbox, acknowledge receipt, and let the assistant organise it for later attention.
Doorbell	Ask for attention now	Send a bounded notification through the owner's chosen channel. Show received/awaiting response rather than inventing presence or guaranteeing an immediate answer.
Assistant at the door	Help route the visitor's request	Explain public contact options, collect a purpose, and optionally ask a clarifying question. Act only within a narrow public-facing policy.
Private home	Let the owner deal with arrivals	Signed-in Home shows arrivals needing attention and links to Inbox; calendar, tasks, private context and conversations stay private.

First useful slice

• Decide the route/ownership model: instance root can be a personal front door on an owner-designated personal instance; a shared host root remains the product entrance and links to explicit user contact pages. Never choose a recipient by assuming the first account owns the site.
• Reuse existing profile/address identity and inbound mail infrastructure; define home@ as an optional explicit alias on a personal domain, with collision handling. No new mandatory account or mailbox system.
• Provide Leave a message with name, reply address, short message and optional link; add attachments once validation and size limits are in place. Email and web submissions enter the same owned Inbox.
• Give the visitor an honest receipt and optional reply destination; distinguish accepted, delivered and answered. Submission is not permission to publish the content.
• Provide Ring with a short reason and owner-controlled delivery. Owner can disable it, choose availability/quiet hours and require stronger sender verification where needed.
• Rate-limit and deduplicate rings, screen unwanted submissions, support blocking, and fall back to leaving a message when ringing is unavailable. Do not launch a paid model run for every visitor action.
• Let the owner reply, defer, dismiss/block or turn an arrival into a task. Preserve sender identity and the arrival's source thread.
• Publish only owner-selected information. Never disclose private calendar availability, location, household details, presence or remembered context to a visitor.
• Treat inbound text/files as untrusted material, not instructions to the private assistant. Visitors cannot authorize sending, spending or changing the owner's data.
• Verify the complete mobile journey: visit -> leave/ring -> owner receives -> owner replies -> visitor receives a response, including offline owner, quiet hours, anonymous sender, abuse and duplicate delivery.

Later, only if useful

Known contacts can have different interruption privileges; invitations and links can be summarised into a reading queue or brief; the assistant can coordinate a callback within explicit owner policy. Avoid a general public chatbot, a social feed, a permanently open call, or a second Inbox as prerequisites.

This issue is a product proposal and implementation checklist. It does not create a live alias, expose owner information or enable visitor notifications.

Addressing proposal — home identity, destination and recipient

Discussed after the initial front-door proposal. Record this as a preferred direction to validate, not an already implemented addressing contract.

A home exists independently of its residents and hosting server. Give it a generated internal ID. Treat public domains and mailbox names as addresses/aliases attached to that identity, rather than making a person's chosen username the identity of the home.

Illustrative hosted addresses:

Meaning	Example
Hosting domain / street	micro.mu
Assigned home / front door	1042.micro.mu
Household letterbox	home@1042.micro.mu
Named resident	asim@1042.micro.mu
Another resident	ruby@1042.micro.mu
Display name	Asim's home

The assigned home number only needs to be unique within its hosting domain. The immutable internal home ID is separate from that number. A friendly display name can change without moving the home. Whether assigned labels should be sequential numbers or short opaque identifiers remains open; public numbering must not be treated as authorization.

Hosting and portability

• Hosted by Micro: supply the home and its assigned subdomain together.
• Self-hosted using a Micro address: would require an explicit address service, DNS delegation or relay that connects the assigned subdomain to the owner's server. This remains dependent on Micro's domain service even though execution/storage is self-hosted.
• Self-hosted on the owner's domain: e.g. asim@aslam.org and home@aslam.org. The runtime must operate independently of Micro registration.
• Custom domain is optional: a user can begin with an assigned address, then attach a verified domain. Preserve aliases where the domain owner permits; a permanent internal ID cannot by itself keep an abandoned public email address reachable.
• A home subdomain does not require a separate purchased domain or server for every home; ordinary DNS/mail routing can direct many home domains to shared infrastructure.

Alternatives considered

• asim+home@micro.mu or home.asim@micro.mu: possible convenience aliases, but they combine home and person in one mailbox name and leave the routing rules specific to Micro. Do not make them the primary identity scheme.
• asim@home.micro.mu: identifies a recipient under one shared destination but does not itself distinguish multiple homes.
• 1@home.micro.mu: can identify a home letterbox but leaves named residents needing another convention.
• Custom domain per home: attractive for independent ownership and portability, but should not impose domain purchase/setup on every user.

Decisions required before implementation

• Home membership and ownership, including multiple residents and private versus household correspondence. A shared domain does not imply shared access to everyone's mail.
• Assigned-label allocation, reserved names, verified aliases, domain ownership checks and safe non-reuse after deletion.
• Compatibility with existing asim@micro.mu addresses and links; no forced renaming of current accounts.
• Shared-host routing, certificates, mail acceptance/delivery and optional self-hosted relay boundaries.
• Moving a home between hosts, preserving internal identity and explicitly communicating which public addresses continue working.
• Address recovery and transfer without exposing previous residents' correspondence.

Technical references: SMTP mailbox/domain and MX routing, site-specific subaddressing conventions.