Swn

Swn aims to be a live chat app with servers and channels, inspired by Discord-style permissions.

Product goals

• Users can belong to multiple servers.
• Servers are invite-only. The creator auto-joins as owner and cannot leave without transferring ownership or deleting the server.
• Each channel is a separate chat stream.
• A new server starts with a General channel.
• The primary app UI is a 4-column layout:
  • a slim server icon rail (50px) with join/create server controls
  • a wider channels column
  • a chat/messages column
  • a member presence column (online/offline), hideable for wider chat view
• Users can have avatars generated from display-name initials by default.
• Users set a display_name during registration and can update it later in account settings.
• Chat identity display uses server nickname when present, otherwise user display_name.
• User email addresses are account credentials and are not shown to other users in chat surfaces.

V1 implementation tracking

The complete V1 checklist and architecture tasks are tracked in V1_TASK_LIST.md.

Practical "done means done" guardrails (especially UI parity checks) are tracked in V1_COMPLETION_GUARDRAILS.md.

Architecture decisions and system design are documented in ARCHITECTURE.md.

Permission bit assignments are documented in PERMISSION_CATALOG.md.

Contributor implementation guidance for chat domain changes is documented in CHAT_CONTRIBUTING.md.

Chat message markdown rendering uses mdex with syntax highlighting enabled and markdown images disabled in rendered output for V1 safety.

V1.1 permission capability changelog

Newly active permission-gated capabilities:

• manage_messages: message delete moderation controls in channel message list.
• mention_everyone: @everyone/@here mention enforcement with denial feedback.
• send_tts_messages: composer TTS toggle with permission gating.
• change_nickname and manage_nicknames: nickname editing in member management dialog.
• timeout_members: apply/update/clear timeout controls with message-send blocking.
• create_invite: server-wide and channel-scoped invite creation from settings.
• add_reactions: reaction toggle controls on messages.
• attach_files: composer file uploads with permission gating.
• embed_links: URL send enforcement and inline link preview cards.

Identity and privacy updates:

• Registration now requires display_name in addition to email.
• Account settings include display-name editing.
• Member/message labels in chat prefer server nickname, then fallback to display name.
• Peer-facing chat UI no longer exposes user email addresses.

Key decisions already locked for V1:

• Multi-server memberships from day one.
• Discord-like role permissions using integer bitsets (targeting fewer than 40 permissions for now).
• Hidden owner semantics via servers.owner_id.
• Non-deletable server-level @everyone role.
• Member-specific channel overwrites plus role overwrites.
• ADMINISTRATOR permission semantics and role hierarchy enforcement.
• Audit logs stored in the same database for V1 (focused on admin/security actions, not per-message events).

Dev

To start your Phoenix server:

• Run mix setup to install and setup dependencies
• Start Phoenix endpoint with mix phx.server or inside IEx with iex -S mix phx.server

Now you can visit localhost:4000 from your browser.

Ready to run in production? Please check our deployment guides.

Learn more

• Official website: https://www.phoenixframework.org/
• Guides: https://hexdocs.pm/phoenix/overview.html
• Docs: https://hexdocs.pm/phoenix
• Forum: https://elixirforum.com/c/phoenix-forum
• Source: https://github.com/phoenixframework/phoenix