Project proposals
Project proposals on this wiki are pages that describe a piece of work someone could build, study, or organize, written so readers can judge scope, risks, and next steps without treating the page as a finished product, a company pitch, or a call to send private data. A proposal page should say what problem it targets, what already exists, what would be new, and what limits remain. It should not invent statistics, quote people without sources, or publish confidential information about any person.
How to use this list
Use this hub as a starting index. Open a linked proposal when you want the full argument. Treat each proposal as a discussion draft until implementers publish working code, configs, or results elsewhere. If a proposal names tools, read those tools as building blocks described at a high level, not as install instructions copied onto this page.
When you add a new proposal, keep the first paragraph honest about status, separate verified software from unfinished design, link only pages that already exist, and prefer plain language over hype.
Criteria for proposals here
Legal and ethical fit: the page must not instruct crime, weapons misuse, or exploitation. It must not recruit into a named financial product or circulate private contact data. Security and safety proposals may discuss malware and abuse as problems to detect. They must not provide attack steps.
AdSense-friendly explainer tone: educational overview, no shock bait, no medical dosing, no investment advice, no wallet setup recipes. Keep examples generic.
No private data: do not paste .env files, keys, personal addresses, phone numbers, or internal chat. If a proposal is about preventing leaks, describe classes of secret, not real secrets.
Length and structure: a focused proposal can be a long article with sections, conclusion, See also, and categories. A hub page like this one stays short and points outward.
Proposal pages and neighbors
Pre-publish checks for MediaWiki and Git is a proposal for layered review before wiki saves and Git pushes, especially when permanent or content-addressed publishing makes mistakes hard to erase. It discusses malware and spam links, abuse text, accidental secrets, and PII, and it separates existing tools from the combined pipeline idea. Until that page is published on this wiki, find it by title after it goes live. Do not treat a missing title as an existing link.
Other pages already on the wiki fit the same spirit of practical design notes. Agent-to-agent commerce outlines how software agents discover peers, agree on terms, pay, and keep records, plus failure modes and guardrails. Post-scarcity economy is a hub overview of which goods get cheaper and which stay scarce. Semi-private basic income through credit unions and nonprofits frames a delivery idea without promoting a named program. Longevity escape velocity as a policy target keeps a research-pace goal separate from clinic advice.
Permanence and wiki infrastructure pages support proposal work even when they are not labeled proposals. Content-addressed wikis, permaweb basics, revision hashing, and educational knowledge-graph notes explain why publish-time care matters.
How to read a proposal
Ask what problem is named, what already exists, what builders would ship, and what could go wrong for users or bystanders. Missing answers mean the page is still a sketch. Prefer proposals that admit false positives, privacy tradeoffs, and non-goals over promises of total safety or effortless automation.
Conclusion
Project proposals on IdeaWaza are structured idea pages for buildable or researchable work. Use this hub to find them, apply the legal, ethical, and privacy criteria before expanding a draft, and keep verified tools distinct from unfinished designs. Strong proposals stay specific about limits and leave private data out of the record.