BIThub Alpha Limits & Suggestions

iamcapote · Mei 26, 2026, 4:18pm

BIThub Alpha Limits

BIThub is in alpha.

Alpha means usable, evolving, and not final.

Expect limits.

Plan around them.

BIThub runs on Discourse.

Some limits are inherited from Discourse, plugins, server settings, moderation settings, or category configuration.

Expect limits around:

post length
reply rate
title length
edit windows
upload size
upload types
mentions
notifications
search behavior
private messages
category access
trust-level progression
spam prevention

Do not assume every limit is custom BIThub policy.

Some limits are platform-layer constraints.

1. Trust-Level and Anti-Spam Limits

New users do not receive full access immediately.

Trust levels protect the platform from spam, low-signal content, abuse, and compute waste.

These limits also exist to slowly rollout user features.

Limits may apply to:

posting
replying
editing
uploading
private messaging
marketplace posting
AI usage
category visibility
advanced workflows

flowchart LR
    T0[TL0 New] --> T1[TL1 Basic]
    T1 --> T2[TL2 Member]
    T2 --> T3[TL3 Regular]

    classDef low fill:#3f1d1d,color:#fff,stroke:#ef4444;
    classDef mid fill:#3b2f14,color:#fff,stroke:#f59e0b;
    classDef high fill:#143f2a,color:#fff,stroke:#22c55e;

    class T0 low;
    class T1,T2 mid;
    class T3 high;

Trust levels are access controls.

They are not badges only.

2. Membership and Access Limits

Some features require:

account login
membership approval
trust-level progression
paid access
staff approval
category permission
tool permission
model permission

Access can change during alpha.

A feature visible today may become restricted later.

A restricted feature may become available later.

3. Upload Limits

Uploads may fail because of:

file size
file count
file extension
trust level
category rule
server limit
moderation rule
storage policy

Use clear filenames.

Good:

wallet-analysis-workflow-v1-2026-05-26.md

Bad:

final_FINAL_REAL_USE_THIS_one!!!.zip

4. Restricted File Types

Prefer readable formats:

.md
.txt
.csv
.json
.yaml
.pdf
.png
.jpg
.webp

Avoid:

executables
unknown binaries
obfuscated scripts
credential dumps
private key files
seed phrase files
large raw archives
database exports with private data
files you do not have permission to share

Blocked uploads are not always bugs.

Some blocks are security controls.

5. Private Messages Are Not End-to-End Encrypted

Private messages are limited-access forum topics.

Private topics are limited-access forum topics.

They are not end-to-end encrypted.

Do not send:

passwords
API keys
private keys
seed phrases
government IDs
medical data
financial account details
unreleased business material
confidential research data
private information about another person

Use proper external security tools for secrets.

6. Private Context and Admin Oversight

Private posts are gated to the user and authorized participants.

AI tools you use may reference your private posts when the tool has permission to operate inside your private context.

Your private posts are not available to other normal users.

Other users’ private posts are not available to your AI context.

Administrators should be assumed to have complete platform oversight.

Private areas are private from other users

They are not private from platform administration, moderation, infrastructure operators, logs, or authorized maintenance workflows.

Treat BIThub private areas as controlled workspaces, not zero-knowledge storage.

flowchart LR
    U[You] --> P[Your Private Posts]
    P --> A[Your AI Context]
    O[Other User] -. blocked .-> P
    P --> ADM[Admins / Operators]

    classDef private fill:#102a43,color:#fff,stroke:#38bdf8;
    classDef blocked fill:#3f1d1d,color:#fff,stroke:#ef4444;
    classDef admin fill:#3b2f14,color:#fff,stroke:#f59e0b;

    class U,P,A private;
    class O blocked;
    class ADM admin;

7. Public Posts May Become Reusable Knowledge

Public posts may be indexed, summarized, refined, cited, reused, or incorporated into BIThub and BITwiki knowledge systems.

Do not publish:

credentials
private messages
leaked documents
copyrighted files
restricted datasets
proprietary code
confidential research
private information about another person
material you do not have permission to share

Write public posts as durable reference material.

8. AI Tools Can Be Wrong

BIThub AI tools can:

hallucinate
miss context
cite weak sources
retrieve stale material
produce incomplete code
misunderstand instructions
overfit to the prompt
invent connections
omit caveats
fail silently

AI output is not authority.

Verify before using AI output in:

production systems
security decisions
financial decisions
legal work
medical work
research publications
public claims
operational planning

9. AI Quotas and Compute Limits

AI access is not unlimited.

Limits may apply by:

trust level
membership tier
model cost
model provider
daily quota
category
Core
Node
Workspace
runtime
message length
backend availability
moderation status

flowchart LR
    A[Request] --> B{Permission}
    B -- denied --> C[Blocked]
    B -- allowed --> D{Quota}
    D -- exhausted --> E[Retry later]
    D -- available --> F[Run]

    classDef gate fill:#111827,color:#fff,stroke:#38bdf8;
    classDef stop fill:#3f1d1d,color:#fff,stroke:#ef4444;
    classDef run fill:#143f2a,color:#fff,stroke:#22c55e;

    class A,B,D gate;
    class C,E stop;
    class F run;

10. AI Mode Limits

Use the correct AI mode.

Wrong tool choice wastes quota and produces weaker output.

flowchart TD
    A[Task] --> B{Simple answer?}
    B -- yes --> C[AI Bot]
    B -- no --> D{Structured analysis?}
    D -- yes --> E[Core]
    D -- no --> F{Repeatable command?}
    F -- yes --> G[Node]
    F -- no --> H[Workspace]

    classDef gate fill:#111827,color:#fff,stroke:#38bdf8;
    classDef tool fill:#102a43,color:#fff,stroke:#60a5fa;

    class A,B,D,F gate;
    class C,E,G,H tool;

Use:

AI Bot for normal reasoning, drafting, summarizing.
Core for structured multi-phase analysis.
Node for narrow repeatable workflows.
Workspace for app-like task interfaces.

11. AI Bots

AI Bots are best for:

drafting
summarizing
reasoning
rewriting
comparing options
working inside permitted context

Limits:

quota-bound
model-bound
permission-bound
context-bound
message-size-bound
not automatically correct
may reference private context only when authorized

Do not use AI Bots as secret storage.

12. Cores

Cores are structured workflow engines.

They are not normal chatbots.

Hard edges:

first post matters
may execute once
may not accept mid-run corrections
may not resume after completion
may produce staged outputs
may treat the first post as seed context
may require a new topic for a new run

sequenceDiagram
    participant U as User
    participant T as First Post
    participant C as Core
    participant O as Outputs

    U->>T: Write seed context
    T->>C: Trigger run
    C->>O: Phase 1
    C->>O: Phase 2
    C->>O: Final output

Strong Core first posts include:

problem
context
constraints
sources
required output
forbidden assumptions
success criteria

Template:

## Problem

State the problem.

## Context

Give only relevant context.

## Constraints

List hard limits.

## Sources

Link or attach evidence.

## Required Output

Define format.

## Success Criteria

Say what a good result must satisfy.

13. Nodes

Nodes are specialized workflow terminals.

They are narrow by design.

Hard edges:

one Node usually has one job
command format may matter
normal chat may not trigger execution
runtime may be limited
tool access may be restricted
output may stream as logs
each Node has its own rules

Before using a Node:

read the topic instructions
follow command syntax
keep input scoped
avoid unrelated context
paste only needed data
record the command used
report failures with timestamp and output

14. Workspaces

Workspaces are app-like interfaces for focused tasks.

During alpha, a Workspace may be:

incomplete
unstable
restricted
experimental
changed without notice
different from chat behavior
different from Node behavior
different from Core behavior

Save important Workspace outputs locally.

15. Search and Memory Limits

Search, semantic retrieval, summaries, and AI context recall may miss relevant material.

Known issues:

stale context
duplicate results
weak ranking
missing posts
incomplete retrieval
summarization loss
hallucinated connections
over-weighting recent posts
under-weighting older canonical posts

Search before posting.

Link relevant prior threads manually when accuracy matters.

16. Outages and Provider Instability

BIThub depends on multiple layers.

digraph G {
  graph [rankdir=LR, bgcolor="transparent"];
  node [shape=box, style="rounded,filled", fontname="Inter", fontsize=11, fillcolor="#111827", fontcolor="#ffffff", color="#64748b"];
  edge [color="#64748b"];

  User [fillcolor="#0f172a", color="#38bdf8"];
  Forum [label="Discourse"];
  AI [label="AI Tools", fillcolor="#102a43", color="#60a5fa"];
  APIs [label="Model APIs", fillcolor="#3f1d1d", color="#ef4444"];
  Output [label="Output", fillcolor="#143f2a", color="#22c55e"];

  User -> Forum -> AI -> APIs -> Output;
}

Failure causes include:

model outage
provider rate limit
plugin update
server maintenance
workflow crash
background job failure
permission change
quota exhaustion
moderation action

A feature can work today and fail tomorrow.

That is alpha reality.

17. Temporary Workflow Instability

Experimental workflows may show:

delayed replies
duplicate replies
incomplete outputs
broken formatting
failed tool calls
missing citations
stalled workflows
wrong category behavior
permission errors
inconsistent model behavior
partial context retrieval

Use experimental workflows for testing, research, prototyping, and feedback.

Do not treat them as production-grade systems.

18. Evolving Permissions

Permissions are not final.

Access may change for:

categories
tags
marketplace rights
private areas
public areas
AI bots
Cores
Nodes
Workspaces
model access
posting rights
upload rights
moderation rights

Permission changes may reflect:

safety fixes
cost controls
workflow cleanup
governance changes
abuse prevention
stability tuning

19. Keep Backups

BIThub should not be your only source of truth.

Keep local backups of:

long posts
drafts
prompts
datasets
code
diagrams
generated outputs
uploaded files
workflow notes
project documentation

flowchart LR
    A[Important Work] --> B[Local Backup]
    B --> C[BIThub Post]
    C --> D[Canonical Link]

    classDef safe fill:#143f2a,color:#fff,stroke:#22c55e;
    classDef work fill:#102a43,color:#fff,stroke:#38bdf8;

    class A,C,D work;
    class B safe;

Temporary topics can expire.

Drafts can fail.

Permissions can change.

Categories can be reorganized.

Keep your own copy.

20. What to Expect

Expect:

changing permissions
quota limits
model variance
rough UI edges
occasional downtime
incomplete documentation
unstable experimental tools
strict moderation
evolving categories
broken workflows
high signal expectations

Do not expect:

unlimited AI usage
permanent free compute
production reliability
secure secret storage
unrestricted scraping
unrestricted automation
unrestricted marketplace posting
instant support for every file type
every AI output to be correct
every workflow to remain unchanged

21. Good Alpha Feedback

Weak report:

It broke.

Useful report:

In the Etherscan Analyst Node, I submitted this command at 2026-05-26 14:20 AST.

I expected a wallet summary.

The workflow returned no output after 4 minutes.

Screenshot, command, topic link, and timestamp are attached.

Report template:

## Limit or Failure

Describe the issue.

## Location

Topic, category, Node, Core, or Workspace.

## Input

What you submitted.

## Expected Result

What should have happened.

## Actual Result

What happened.

## Time

Date, time, timezone.

## Impact

Why this blocks work.

## Evidence

Screenshots, logs, links.

22. How to Overcome Some Limits

You cannot remove all alpha limits.

You can reduce friction without bypassing platform controls.

Goal:

preserve work
reduce quota waste
improve retrieval
reduce clutter
avoid privacy mistakes
keep useful knowledge clean

22.1 Purge Finished Private Work

When a private topic, message, upload, or scratchpad is no longer useful, delete it or request removal where deletion is not available.

This reduces clutter.

It lowers accidental context pollution.

It makes future AI retrieval cleaner.

Use private topics as working memory.

Do not use them as permanent archives unless they are intentionally curated.

flowchart LR
    A[Private Draft] --> B[AI Work]
    B --> C[Extract Final]
    C --> D[Backup]
    D --> E[Purge Scratch]

    classDef work fill:#102a43,color:#fff,stroke:#38bdf8;
    classDef safe fill:#143f2a,color:#fff,stroke:#22c55e;
    classDef purge fill:#3f1d1d,color:#fff,stroke:#ef4444;

    class A,B work;
    class C,D safe;
    class E purge;

Recommended pattern:

Create private workspace topic.
Run the work.
Extract final useful output.
Save your local copy.
Delete or archive scratch material.
Keep only canonical notes.

22.2 Keep Canonical Topics Small

Long messy topics degrade readability and retrieval.

Split work into focused topics:

problem
source collection
implementation
final documentation
bugs
follow-up work

Small topics are easier to search, summarize, moderate, cite, and purge.

22.3 Use a Canonical Final Post

After a long discussion, create one clean final post.

Include:

final answer
decisions made
source links
unresolved questions
next action
version/date
owner or maintainer

Mark older exploratory topics as scratch, temporary, archived, or obsolete.

22.4 Separate Scratch from Reference

Do not mix rough brainstorming with permanent documentation.

Use status labels:

Scratch
Draft
Experiment
Canonical
Deprecated
Reference
Archive

Example titles:

[Scratch] Testing prompt variants for wallet analysis
[Canonical] Wallet analysis workflow v1
[Deprecated] Old wallet analysis prompt chain

22.5 Compress Before Posting

Do not paste huge logs, transcripts, or dumps unless needed.

Compress first.

Use:

## Context

What this is about.

## Relevant Data

Only the needed excerpt.

## Failure

Specific failure.

## Request

Exact requested output.

## Raw File

Attach only if needed.

Compression reduces:

token waste
quota use
retrieval noise
moderation overhead
hallucination risk

22.6 Use External Repositories for Heavy Assets

BIThub should not be the only home for large or durable assets.

Use:

GitHub for code
object storage for large files
IPFS for content-addressed artifacts
cloud drive for private archives
local encrypted storage for sensitive files
project wiki for polished documentation

Then post a clean summary and link.

Do not upload large files repeatedly when one stable link is enough.

22.7 Batch AI Work

Avoid wasting quota on scattered prompts.

Bad pattern:

Question.
Another question.
Wait, include this too.
Actually change format.
Try again.

Better pattern:

## Goal

Produce a final implementation plan.

## Context

Relevant facts only.

## Constraints

No private data. Must fit platform limits.

## Output

Checklist plus risk notes.

Before using AI:

Gather context.
Remove irrelevant material.
Define output format.
State constraints.
Ask once.
Review before iterating.

22.8 Clean Context Before Asking AI

Remove:

repeated text
irrelevant logs
old drafts
contradictory instructions
obsolete outputs
unrelated links
private data
vague wording

Add:

objective
constraints
source excerpts
exact output format
known failure mode
current state

Clean context reduces hallucination.

22.9 Version Important Workflows

Version workflows as they evolve.

Example:

Prompt Generator Workflow v0.1
Prompt Generator Workflow v0.2
Prompt Generator Workflow v1.0 Canonical

Use changelog blocks:

## Version

v0.3

## Changed

- Reduced input size
- Added source checklist
- Removed obsolete model reference

## Status

Testing

Versioning prevents old instructions from being mistaken for current instructions.

22.10 Mark Obsolete Material Explicitly

Do not leave old material looking active.

Add this at the top:

> **Status:** Deprecated.
>
> Use this instead: [link to canonical topic].

This helps humans and AI avoid stale context.

22.11 Use Temporary Topics Intentionally

Temporary topics are useful for:

one-off tests
prompt experiments
messy drafts
transient logs
AI scratch work
short-lived coordination

Do not put durable knowledge only in temporary areas.

Before expiration:

extract what matters
move it to a canonical topic
save a local backup
let the scratch topic disappear

22.12 Reduce Upload Failures

Before uploading:

compress images
remove unused pages
export large docs to PDF
split massive files
rename files clearly
remove special characters from filenames
avoid duplicate versions
strip credentials and private data

22.13 Ask for Permission Changes with a Use Case

Do not ask for “more access” generically.

Use:

## Requested Permission

Name the permission.

## Use Case

Explain the work.

## Needed Duration

Temporary or permanent.

## Risk

What could go wrong.

## Mitigation

How you will avoid abuse, spam, or data leaks.

## Expected Benefit

What this enables for BIThub.

Good permission requests are easier to approve.

22.14 Report Limits Instead of Fighting Them

Some limits are bugs.

Some limits are protection.

Useful reports help admins decide whether to raise, document, or preserve the limit.

Report:

where it happened
what triggered it
what you expected
what happened instead
why it blocks legitimate work
screenshots or logs
timestamp and timezone

22.15 Do Not Bypass Limits

Do not bypass:

rate limits
upload restrictions
trust gates
file restrictions
private boundaries
anti-spam controls
automation rules

Work with the system.

If a limit blocks legitimate work, document it and request an adjustment.

Bypassing limits damages trust and may reduce access.

23. Operating Model

Use BIThub in four layers.

flowchart LR
    A[Scratch] --> B[Refine]
    B --> C[Canonical]
    C --> D[Archive]

    classDef scratch fill:#3b2f14,color:#fff,stroke:#f59e0b;
    classDef refine fill:#102a43,color:#fff,stroke:#38bdf8;
    classDef canon fill:#143f2a,color:#fff,stroke:#22c55e;
    classDef archive fill:#111827,color:#fff,stroke:#94a3b8;

    class A scratch;
    class B refine;
    class C canon;
    class D archive;

Scratch: temporary work, tests, messy AI runs.
Refine: cleaned drafts, reviewed outputs, structured notes.
Canonical: final durable knowledge.
Archive: old but preserved material.

This model reduces alpha friction without bypassing platform controls.