| title | description | category | tags | difficulty | related-docs | last-updated | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Administrator Guide |
Administrative functions, security management, and platform configuration guide for Fairfield administrators |
howto |
|
advanced |
|
2026-01-16 |
This guide covers administrative functions, security management, and platform configuration for Fairfield administrators.
- Admin Overview
- Accessing the Admin Panel
- User Management
- Channel Management
- Section Management
- Calendar Management
- Security Monitoring
- Whitelist Management
- Rate Limiting
- Troubleshooting Admin Issues
Administrators have elevated privileges to manage users, channels, sections, and monitor platform security.
| Feature | Admin Can |
|---|---|
| User Management | Approve/reject access requests, assign cohorts |
| Channel Management | Create, edit, delete channels |
| Section Management | Configure section access rules |
| Calendar | Full visibility, create/edit events |
| Security | View activity logs, manage whitelist |
- Must be whitelisted with
admincohort - Admin pubkey configured in environment variables
- Server-side verification via relay API
- Log in with your admin nsec/hex key
- Navigate to
/adminin the URL bar, OR - Click "Admin" in the navigation menu (visible only to admins)
Admin access is verified in two ways:
- Client-side: Shows admin UI elements
- Server-side: All actions verified against relay whitelist
Security Note: Even if someone bypasses client-side checks, all admin actions are validated server-side via
verifyWhitelistStatus().
If you see "Access denied: Admin privileges required":
- Verify your pubkey is in the admin whitelist
- Contact another admin to check your cohort assignment
- Wait 2 seconds - you will be redirected to chat
- Go to Admin Panel > Access Requests
- See all pending section access requests
- Each request shows:
- User's pubkey (truncated)
- Requested section
- Request timestamp
- Optional message
- Find the pending request
- Click "Approve"
- User is added to the section's whitelist
- User receives full section access immediately
- Find the pending request
- Click "Reject"
- Optionally add a rejection reason
- Request is removed from pending list
Users can be assigned to cohorts with different permissions:
| Cohort | Description | Can Self-Assign |
|---|---|---|
admin |
Full administrative access | No |
approved |
Standard approved user | No |
business |
Business section access | No |
moomaa-tribe |
Special community access | No |
- Go to Admin Panel > Whitelist
- Find the user by pubkey
- Select new cohort from dropdown
- Click "Update"
Warning: You cannot remove your own admin cohort (safety feature).
The User Management panel (/admin/users) provides a comprehensive interface for managing user zone assignments:
| Zone | Colour | Description |
|---|---|---|
| Family | Green (#4a7c59) | Family community section |
| DreamLab | Pink (#ec4899) | DreamLab creative space |
| Minimoonoir | Purple (#8b5cf6) | Minimoonoir community |
| Admin | Red (#ef4444) | Full administrative access |
- Pagination: Navigate through users 10/20/50/100 at a time
- Search: Find users by display name or pubkey
- Filter by Zone: View only users in a specific zone
- Radio Selection: Single-click zone assignment with visual feedback
- Pending State: Loading indicators while updates process
- Navigate to Admin Panel > User Management
- Browse or search for users
- Click a zone radio button to assign that user to the zone
- The
approvedcohort is automatically preserved - Non-zone cohorts (e.g.,
business) are preserved - Success message confirms the change
// Fetch paginated users
GET /api/whitelist/list?limit=20&offset=0&cohort=family
// Update user cohorts
POST /api/whitelist/update-cohorts
{
"pubkey": "<64-char-hex>",
"cohorts": ["family", "approved"],
"adminPubkey": "<admin-hex>"
}- Go to Admin Panel > Channels
- Click "Create Channel"
- Fill in the form:
- Name: Channel identifier (alphanumeric, hyphens, underscores)
- Section: Which section this channel belongs to
- Description: Brief description (optional)
- Access Type: Open or Gated
- Click "Create"
| Type | Who Can Post |
|---|---|
| Open | Anyone with section access |
| Gated | Only channel members |
- Navigate to the channel
- Click "Edit Channel" (gear icon)
- Modify settings
- Click "Save"
- Navigate to the channel
- Click "Delete Channel"
- Confirm the deletion
Warning: Deleting a channel does not delete messages. Messages remain on the relay but are no longer displayed.
| Section | Default Access |
|---|---|
| Fairfield Guests | Open (auto-approved) |
| Fairfield | Requires approval |
| DreamLab | Requires approval |
View section stats in Admin Panel > Stats:
- Number of channels
- Number of approved users
- Pending access requests
- Recent activity
Section access is controlled by the whitelist system:
- User requests access to a section
- Request appears in admin panel
- Admin approves or rejects
- User is added to section cohort
Admins have full calendar visibility:
- All event details visible
- No masking regardless of cohort
- Can edit/delete any event
- Go to Events > Create Event
- Fill in event details:
- Title
- Date and time
- Location
- Description
- Cohort visibility (optional)
- Click "Create Event"
Events can be tagged with cohorts to control visibility:
Tags: ["cohort", "business"]
Users not in the tagged cohort will see:
- Date/time (availability only)
- "Event details restricted" message
- Click on an event
- Click "Edit"
- Modify details
- Click "Save"
The admin panel displays security alerts:
| Severity | Type | Description |
|---|---|---|
| HIGH | self_admin_attempt |
User tried to self-assign admin |
| HIGH | invalid_signature |
Event signature verification failed |
| MEDIUM | unauthorized_action |
Non-admin attempted admin action |
| LOW | rate_limit_exceeded |
Too many requests |
- Go to Admin Panel > Security
- View recent suspicious activities
- Filter by severity or type
The system automatically tracks:
- Unauthorized cohort change attempts
- Invalid signature submissions
- Rate limit violations
- Author/pubkey mismatches
- Replay attack attempts
The whitelist is stored on the Nostr relay using NIP-51 pin lists (kind 30001).
- Go to Admin Panel > Whitelist
- See all whitelisted users
- View their cohorts and approval dates
- Click "Add User"
- Enter the user's pubkey (hex format)
- Select cohort(s)
- Click "Add"
- Find the user in the whitelist
- Click "Remove"
- Confirm removal
Note: Removed users lose section access immediately but can request again.
The relay provides a verification API:
GET /api/check-whitelist?pubkey=<64-char-hex>
Returns:
{
"isWhitelisted": true,
"isAdmin": false,
"cohorts": ["approved", "business"]
}Admin actions are rate-limited to prevent abuse:
| Action | Max Attempts | Window | Backoff |
|---|---|---|---|
| Section Access | 5 | 1 minute | 2x |
| Cohort Change | 3 | 1 hour | 3x |
| General Admin | 10 | 1 minute | 1.5x |
After exceeding limits:
Attempt 1: Immediate
Attempt 2: windowMs * 2
Attempt 3: windowMs * 4
...
Maximum: maxBackoffMs
If you're rate-limited:
- Wait for the cooldown period
- Try again after the specified time
- Contact another admin if urgent
Issue: "Access denied" error
- Verify your pubkey is in the admin whitelist
- Check that
VITE_ADMIN_PUBKEYincludes your pubkey - Try logging out and back in
Issue: User still cannot access section after approval
- Check the relay connection
- Verify the approval event was published
- Ask the user to refresh their page
Issue: Changes not reflecting
- Wait a few seconds for relay sync
- Refresh the admin panel
- Check browser console for errors
Issue: "Too many requests" error
- Wait for the cooldown period (shown in error)
- Admin actions have strict rate limits
- Contact another admin if urgent
Issue: Seeing HIGH severity alerts
- Note the pubkey involved
- Check if it's a legitimate user
- Review their recent activity
- Consider removing from whitelist if malicious
- Use a dedicated admin key - Don't use your personal key for admin
- Store admin key securely - Hardware security key if possible
- Rotate keys periodically - Change admin key if compromised
- Minimize admin count - Only grant admin to trusted users
- Review admin actions - Check security logs regularly
- Verify before approving - Confirm user identity if possible
- Check security logs daily - Look for suspicious patterns
- Monitor rate limit events - May indicate attack attempts
- Review pending requests - Don't let them accumulate
// Check rate limit before action
import { checkRateLimit } from '$lib/nostr/admin-security';
const result = checkRateLimit('cohortChange', pubkey);
// Verify whitelist status
import { verifyWhitelistStatus } from '$lib/nostr/whitelist';
const status = await verifyWhitelistStatus(pubkey);
// Log suspicious activity
import { logSuspiciousActivity } from '$lib/nostr/admin-security';
logSuspiciousActivity({
type: 'unauthorized_action',
actor: pubkey,
details: { action: 'attempted admin access' }
});import { validateCohortAssignment } from '$lib/nostr/admin-security';
const result = validateCohortAssignment({
targetPubkey: userPubkey,
cohort: 'approved',
assignerPubkey: adminPubkey
});# Google Cloud Project
GOOGLE_CLOUD_PROJECT=your-project-id
# Admin public key (hex format)
VITE_ADMIN_PUBKEY=64-character-hex-pubkey
# Relay URL (Cloud Run)
VITE_RELAY_URL=wss://nostr-relay-<PROJECT_NUMBER>.us-central1.run.app
# Optional: Multiple admin pubkeys (comma-separated)
VITE_ADMIN_PUBKEYS=pubkey1,pubkey2,pubkey3# Embedding API for semantic search
VITE_EMBEDDING_API_URL=https://embedding-api-<PROJECT_NUMBER>.us-central1.run.app
# Image upload API
VITE_IMAGE_API_URL=https://image-api-<PROJECT_NUMBER>.us-central1.run.app# List all Cloud Run services with URLs
gcloud run services list --format="table(SERVICE,REGION,URL)"
# Example output:
# SERVICE REGION URL
# embedding-api us-central1 https://embedding-api-617806532906.us-central1.run.app
# image-api us-central1 https://image-api-617806532906.us-central1.run.app
# nostr-relay us-central1 https://nostr-relay-617806532906.us-central1.run.appFor CI/CD deployments:
| Secret | Description |
|---|---|
GOOGLE_CLOUD_PROJECT |
GCP project ID |
GCP_SERVICE_ACCOUNT_KEY |
Service account JSON for deployments |
Last updated: January 2025