Your world. Our commons. Evidence before change.

The browser is the primary work area. The server receives the smallest artifact the person deliberately chooses to share.

1. Every share operation must show the exact content, attachments, audience, attribution, permissions and destination before sending. A changed payload or audience requires a new confirmation.
2. Separate private recovery backups from shareable releases. Shared schemas use explicit allowed fields and exclude private world identifiers, revision history, activity logs, reports, location trails, credentials, hidden metadata and unrelated drafts by default.
3. Providers, live cameras, external pictures, maps and other remote services can learn about a request. Show the destination and purpose before sending private input; external Social pictures require a deliberate load action.
4. No behavioral advertising, political profiling, sale of personal data or automatic training on visitor work is part of this design. Optional paid services must describe their price and data destination before use.
5. Browser storage can be denied, exhausted, evicted or cleared. A storage dashboard, persistence requests, portable backups and tested restoration are required work; local storage alone is not encryption or a backup.
6. Unsharing stops future access through MORIverse where enforceable. It cannot recall somebody else’s download, screenshot or independent copy. Explain that before publication.
7. Protect the delivered app as well as the database: strict content boundaries, inert imports, minimal third-party code, dependency review and least-privilege access. Browser data is still vulnerable to malicious same-origin scripts, compromised devices and hostile software updates.

A proposal may explain a possibility. A shared release must demonstrate a benefit within its stated context.

1. Define the problem, intended beneficiaries, unchanged baseline, candidate, success measure and unacceptable regressions before the comparison. Likes, contributor seniority, repetition and MORI’s confidence do not substitute for evidence.
2. Engineering changes need reproducible comparisons, recorded conditions, source/test versions and results. Qualitative changes can use a documented task, accessibility review, creative brief or consenting user assessment; one score does not define quality for everybody.
3. Record uncertainty, sample size and conflicting results. A tiny or noisy difference is inconclusive. Failed, disputed, expired or retracted evidence blocks promotion until resolved or retested.
4. Bind evidence to the exact baseline and candidate hashes, shared-world revision and policy version. Any material change invalidates the old approval and starts the relevant checks again.
5. A demonstrated benefit must pass privacy, security, accessibility, consent, compatibility and recovery checks as well. An improvement in speed cannot silently trade away people’s work or rights.
6. MORI issues a reasoned, reproducible review with cited evidence and remaining limits. Finalization requires authorized approvals under the published rules; a browser-supplied “passed” flag cannot authorize a shared write.
7. Retain rejected alternatives and failed experiments within their permitted audience. New evidence can reopen a proposal. Creative work and personal beliefs do not need a scientific proof merely to exist in someone’s private space.

People contribute to a working branch; they do not overwrite the community’s accepted world.

1. Use the sequence: fork the accepted revision → propose a scoped change → test the comparison → MORI review → authorized finalization → monitored release. Keep the baseline and a usable rollback throughout.
2. Contributor, reviewer, world steward and moderator are separate permissions. Material shared changes need an independent reviewer. A contributor does not approve their own promotion; maintainers and MORI follow the same evidence requirements.
3. Automatic merging is suitable for compatible working edits. CRDT convergence is not evidence of improvement, valid consent or permission to publish. Membership revocation and canonical releases require an authoritative boundary.
4. The future server must validate identity, membership, current revision, artifact hashes, policy version, approvals and one-time release requests on every write. Use atomic revision checks and reject stale or replayed finalizations.
5. Record who approved, which evidence was accepted, what changed and how to reverse it. Public summaries must be redacted independently of private review material. Preserve a prior release when the candidate fails.
6. Contributed assets and executable code use different paths. Worlds may accept validated data and licensed media; untrusted scripts and plug-ins need isolated execution and a separate code/security review.
7. Urgent containment can temporarily disable an unsafe shared feature with a logged reason and prompt review. It does not grant a hidden route for ordinary untested feature promotion.
8. Rules themselves are versioned proposals with published rationale, review and notice. Community authority does not silently expand into members’ private worlds.

Design the incentives and enforce observable conduct. A claim about somebody’s hidden agenda is not sufficient grounds for punishment.

1. The public Social commons is for making, learning, sharing work and useful community coordination. Party/candidate campaigning, factional recruitment and antagonistic persuasion drives are outside that purpose across all sides. This limits shared distribution; it does not authorize inspection of private beliefs.
2. People may question policies, criticize institutions, compare sources, describe experiences and disagree. Controversial topics and political identities are not automatic violations. Critique ideas and actions with the same standards across viewpoints.
3. Do not distribute threats, incitement, targeted harassment, doxxing, identity-based dehumanization or organized intimidation. Reports must identify the actual conduct, context and rule; disagreement alone is insufficient.
4. Constrain coordinated flooding, brigading, fake identities used to manipulate reach, undisclosed automated persuasion, impersonation and forged evidence. A large number of reports is a signal to examine, not a vote that determines truth.
5. No paid political promotion or behavioral ad targeting is planned. Disclose relevant sponsorship and automated authorship in public submissions. Do not infer somebody’s politics or sensitive traits from their private activity.
6. Following and chronological views are the default discovery plan. Let people choose topics and communities, mute or block, and control notifications. Do not optimize distribution for anger, argument length, compulsive engagement or recruitment.
7. Use purpose-bound discussion rooms. A constructive contentious post can state its question, distinguish observation from interpretation, link checkable claims, acknowledge uncertainty and explain what response would help.
8. Opinions, jokes, art and personal accounts do not all require academic citations. Label their nature. Evidence links do not excuse harassment, and repetition does not turn a disputed claim into an established fact.
9. For example, comparing evidence about a water policy fits a structured discussion; party recruitment, demands to flood other rooms or attacks on people for their affiliation do not fit the commons. Apply the purpose rule to the submitted behavior, with notice and appeal.
10. Context matters for quotations, satire and documentation of abuse. Keyword matches and topic labels alone must not decide sanctions. High-impact speech decisions need qualified human review and an appeal path.
11. MORI assists with context, sources and policy checks. Moderation must be explainable and challengeable; MORI is not an unaccountable arbiter of acceptable belief. Aim to prevent abuse and amplification, while measuring failures instead of promising zero misuse.

A trustworthy commons must be able to correct both abusive content and its own mistaken decisions.

1. Give affected people a durable notice: the content/action, specific rule and version, relevant excerpt, scope, duration, decision maker, automation involved and an accessible appeal route.
2. Use proportionate actions: request context or revision, apply a clearly explained contextual label, limit a specific distribution path, or remove the violating material. Avoid hidden suppression or collective punishment.
3. Permit appeal to a reviewer who did not make the disputed decision. Preserve the person’s response and original material within restricted access, and restore content/reach where a mistaken action is reversed.
4. Keep reports, reporter identity and private evidence restricted. Publish privacy-reviewed aggregate outcomes, error rates, appeal reversals and rule changes; do not expose private complaint queues or political profiles.
5. Test the same conduct with viewpoints and group labels exchanged. Review cultural/language context, false positives, missed abuse and coordinated-report attacks. No fairness guarantee follows merely from an automated test passing.
6. Authoritative moderation, sanctions and appeals need authenticated services and accountable human operations. These are launch gates for public Social participation, not functioning services in the current local kit.

Owning a website means being able to preserve, operate and move it, with dependencies clearly disclosed.

1. Keep personal creation, editing, export and local MORI evaluation usable without a paid generation provider. Optional models, live feeds and public services must fail clearly without replacing or losing private work.
2. Build and verify an offline app shell with versioned cache updates and recovery. Do not claim a fresh browser can open the entire site without a network until offline installation and cold-start behavior are tested.
3. Prepare a documented deployment package with portable source, asset provenance, schema migrations, environment names, secret setup, backup and restoration instructions. Do not package secrets or visitor records into the release.
4. The current public Site remains hosted on its existing domain. A separately owned domain and independent hosting are a planned migration, not purchases or deployments performed by this charter.
5. Browser storage belongs to an origin. Moving domains needs an explicit, tested export/import bridge for workspaces and separate audio/reading stores; a DNS change does not transfer people’s local data.
6. Use minimal shared services for membership, invitations, selected artifacts, release manifests and moderation. Keep private work local; optional encrypted collaboration must state its key recovery and moderation limits.
7. Encrypted invite-only projects and public moderated content have different trust boundaries. A server cannot inspect encrypted plaintext it never receives. Do not claim both invisible private content and complete server-side moderation.
8. Before claiming independence, test clean installation, offline editing, rejected network requests, export/restore, host migration, shared-service failure, stale clients, rollback and mobile memory/storage limits.