notyraThe relation
One wallet.
A fixed topic.
A yes or a no.
NotyraTopics stores follows(account,topic) as a boolean for topic IDs zero through eleven. The interface gives these twelve slots readable names; the contract does not define feeds, organizations, ranking or content categories beyond those slots.
Your relation becomes active.
Topic count increases by one.
Your relation becomes inactive.
Topic count decreases by one.
Changing choices
The sender owns
the relation.
follow(topic) rejects an unknown topic or an already active relation. unfollow(topic) rejects a relation the sender does not currently have. There is no author input: msg.sender is always the account being changed.
TopicFollowed(account,topic,active) records the exact account, topic and final state. Frontend confirmation checks this event, the contract log address and transaction status, hash, from and to. It does not invent a version parameter or claim a pending-wallet transaction can be cancelled by changing a page.
Reading counts
Count relations.
Do not infer people.
followerCount(topic) counts active wallet-topic relations. Multiple wallets may be controlled by one person. Counts are not proof of unique humans, verified demand, identity, truth, reputation, support, a reward entitlement or investment interest.
The twelve topic names are this interface’s fixed vocabulary. Their labels are not additional contract logic or a claim of external content integration.
Public boundaries
No private inbox.
No hidden service.
A deployed network would make account, topic choices and events public. Unfollowing changes current state but does not erase history. Do not treat a wallet-based list as anonymous or encrypted.
This contract has no notifications, email collection, push delivery, feeds, indexer, content-reading backend, membership gating, token, fee collection, funds or rewards. Both actions are nonpayable; a future deployed transaction consumes native network gas.
Current state
Prepared locally.
Not deployed.
The website, independent topic page, original project contract, local tests and unsigned deployment preview live in the same worktree. The default configuration has no target chain, RPC, address or runtime hash and disables public reads/writes.
The frontend verifies runtime code and account/chain, checks current relation, estimates gas with a buffer, binds reviewed fee caps and transaction chainId, checks balance and expires reviews after sixty seconds. Slow network checks are followed by another expiry check. Input, mode and connection changes invalidate stale reviews.
Practice is page memory only and is never presented as a receipt or network count. This immutable contract has no administrator, proxy or upgrade key; future rule changes require a new reviewed address and explicit migration. Local tests are not an independent audit.
Public signing and deployment require separate authorization through a controlled local signer. No private key belongs in this website, public API, source, logs or records.
Try the local choices