YOUR NEXT TRANSMISSION

One idea. Every channel.

Create your post, choose where it goes, and make it happen.

01

Add your media

One image or video

↥Drop your next great post hereor browse filesJPG, PNG, WebP or MP4 · up to 64 MiB

Photos publish to Facebook. Use an H.264 MP4, 3 seconds–10 minutes, for video channels.

02

Write your caption

03

Choose your channels

Manage accounts ↗

Connect an account to start publishing.

04

Make it happen

Publish nowSend it when you’re readySchedule for laterFind the right moment

Select accounts to continue

BRING YOUR CHANNELS TOGETHER

Your corner of the internet.

Connect Facebook Pages, TikTok accounts, and YouTube channels.

Connected accounts

EVERY POST, ONE PLACE

See how it’s going.

Track schedules, platform results, and every publishing attempt.

MAKE IT YOURS

General Settings

Your workspace, your preferences.

SETTINGS / YOUR PUBLISHING CONTROLS

Publishing Approval

Publishing authorization, notifications, identity, and evidence.

Design preview · not active

These controls are a proposed configuration, not an active publishing policy. Changes here are temporary and are not saved or enforced. The existing publishing flow does not yet require approval. No email, push notification, passkey ceremony, signature, or report is generated by this panel.

01 · Human approval

Proposed policy

Prepare and schedule → validate media and permissions → request approval → approve, revise, or reject → revalidate at dispatch → verify results and issue receipts.

Security modeRequired approversRequest approval before publicationFollow-up reminderMissing approval at scheduled timeSample publication time

Sample timezone: Asia/Manila (UTC+08:00). Production scheduling should store UTC and retain the user's IANA timezone.

Proposed security modes — none are implemented
Capability	Standard	Protected	Strict
Human approval	Optional in source proposal*	Required	Required
Approval identity	Session	MFA / passkey	Passkey + fresh step-up
Two-person approval	No	Optional	Required; preparer cannot be sole approver
Signed receipts, reminders, audit	Planned	Planned	Planned
Revision invalidates approval	Yes	Yes	Yes

*The source proposal's optional automatic publishing conflicts with “no valid approval, no publishing.” The recommended initial implementation requires approval in every mode; no bypass control is offered here. Protected is the proposed solo-creator default; Strict requires a team-role system.

Authorization rules and approval evidence

No response means no consent. Hold or expire the attempt; late approval requires a confirmed new publishing time.
Approve only the exact media bytes/digest, final caption, metadata, platform and account IDs, visibility, scheduled time, publishing options, and revision number.
Record approver identity, authentication method, decision time, approval expiry, and revocation. Early approval remains valid only for unchanged content within its authorization window.
Edits, destination changes, rescheduling, and automatically appended text or links invalidate prior approval.
The worker must independently recheck approval in an atomic dispatch process. Retries that submit new content need valid approval; status polling of an existing platform job may continue.
Revocation prevents future dispatch, but cannot guarantee cancellation after a platform has received the request.
Use idempotency and platform reconciliation. Unknown outcomes require investigation, not blind resubmission.

Approval expiry (proposed)Material changes always invalidate approval

02 · Notifications

No delivery service connected

In-app approval inbox and historyEmail requests, reminders, and receiptsPhone notifications via Web Push / PWASMS backup · later phase

Email needs a transactional provider and a verified recipient. Web Push needs HTTPS, a service worker, and user permission; phone installation requirements vary. This preview never requests notification permission or subscribes a device.

Messages open an authenticated review screen. Proposed email links are short-lived and single-use; opening or scanning a link must never approve a post. Never include OAuth tokens, private media links, or long-lived approval credentials in notifications.

Preview channelPreview event

PXSTER .PHONE · SAMPLE

All examples use fictional content and Asia/Manila time. Nothing is sent or published.

03 · Identity, signatures & attribution

Mechanism	Purpose	Status
Platform OAuth	Delegated platform access; not approval for every future post	Existing adapters; live credentials/review required
User authentication	Identifies the person accessing Pxster	Cookie sessions exist; MFA/passkeys planned
Publishing approval	Authorizes one exact content revision	Reserved, not enforced
Cryptographic signature	Verifies integrity and origin of a signed record	Planned server-side Ed25519 signing
Caption/email signature & link-in-bio	Branding and attribution	Planned; not an authentication mechanism

Approval verificationReceipt signingBranded profile / link-in-bio URLCaption footerCampaign tracking parametersEmail signature

Resolve all branding, footers, and tracking links before approval so they are included in the final preview and hash. These sample fields do not modify composer content.

Security and key handling

Use official OAuth redirects, never store Facebook, TikTok, or Google passwords. Access and refresh tokens are encrypted; scope permissions and support rotation/revocation.
A normal passkey login proves an authentication ceremony, not automatically a signature over the full post payload. Bind step-up evidence to the exact approval revision.
Use a separate server signing key with key IDs, rotation, and public-key verification. Never reuse the provider-token encryption key or put private keys in the browser.
A server signature proves Pxster signed the record; it is not independent proof of human intent or public visibility. Database rows alone are not tamper-proof audit storage.

04 · Receipts, history & reports

Authorization receipt for the approved revisionSeparate execution receipt for each destinationImmediate outcome report24-hour performance report7-day follow-up reportExport format

Keep one parent job and independent Facebook, TikTok, and YouTube results. One platform failure must not hide success on another. Performance reports carry metric fetch timestamps and remain separate from the original publication receipt.

Example PX-20261020-0042 · illustrative only

October Product Launch · revision 3 · Facebook · scheduled October 20, 6:00 PM Asia/Manila.

Production receipts should include the full content SHA-256, approver and verification method, approval/expiry times, platform post ID, attempt timestamps, platform response reference, verification method, immutable event IDs, signature, and signing-key ID. None of these are real evidence in this preview.

Receipt state	Meaning
SUBMITTED	Request accepted; publication not established
PROCESSING	Platform still processing
PUBLISHED	Provider reports publication
PUBLICLY_VERIFIED	Independent visibility check recorded, where supported
FAILED	Known failure
UNKNOWN	Outcome uncertain; reconcile before retrying

These are proposed receipt states; current history uses the existing worker states. A returned ID or successful HTTP request does not prove public visibility. Views, reach, and engagement depend on platform permissions and availability.

05 · Platforms & implementation plan

Platform	Approval behavior
Facebook Pages	Pxster approval before the authorized Page publishing API.
TikTok	Pxster approval plus creator information, explicit consent, visibility, scopes, and required app review. Current adapter targets Direct Post. Upload-to-Inbox would require the creator to finish in TikTok; it is not implemented.
YouTube	Approve before upload or visibility changes; reconcile processing status and applicable API audit restrictions.
Instagram Professional	Future adapter only; eligibility and permissions must be established first.

Pxster approval never replaces platform consent. Polling already exists; verified Meta/TikTok webhook receivers are reserved but not exposed.

Approval engine — immutable revisions, requests, expiry, rejection, revocation, worker dispatch checks, and hold rules.
Email and phone notifications — transactional delivery, secure deep links, PWA/Web Push, reminders, and delivery history.
Strong identity and signatures — passkeys, fresh step-up, canonical content hashes, signed authorization records.
Publishing evidence — reconciliation, signed/exportable receipts, audit history, and timestamped performance reports.

Architecture, records, and reserved API operations

This Pxster repository uses FastAPI, PostgreSQL, a durable database worker, private R2, and Cloudflare. Celery Beat, RabbitMQ, and Redis in the source proposal are optional future infrastructure, not installed dependencies of this app.

Preserve existing posts, connected accounts, media assets, destinations, publish attempts, users, and sessions. Reserved additions: post revisions, approval policies/requests/decisions, notification deliveries/preferences/push subscriptions, passkey credentials/challenges, audit events, receipt artifacts/signing-key metadata, performance reports, and webhook events.

Versioned API namespaces cover post revisions/request-approval, approvals (list/review/approve/reject/revoke), policies, notifications, push subscriptions, passkeys, post audit/receipts/reports. Meta/TikTok webhook and passkey sign-in paths remain unmounted. Existing post creation/history endpoints remain in use.

Every real operation must verify the authenticated user, ownership/tenant, authorization rights, revision, and current state. Namespace placeholders return 501 and perform no action. Keep approval logic independent of social adapters so future platforms and AI-assisted drafting cannot bypass it.

Preview only · no changes are saved