Contributing

Solnix is early (preview-image stage) and every arch needs builders. Contributions welcome.

Repos

Ways to help

• Port an architecture. Each of aarch64, SPARC v9, and RISC-V needs work — and each needs a builder that can produce artifacts for the cache.
• Package illumos software. Grow pkgs.solnix.*.
• The seed toolchain. Help harden the stage0 extraction from illumos-gate.
• Docs. Every page here has an edit link (top right).

Mailing lists

Development discussion happens on hackers@solnix.io; announcements and the weekly digest on announce@solnix.io. Subscribe on the community page. Confirmation links expire after 24 hours; opening one shows a confirmation form, and pressing its button completes signup. Each list email includes unsubscribe.

Confirmation proves address ownership, not posting trust. New senders are moderated. Automatic posting to hackers requires a confirmed subscription, explicit moderator vetting, no ban, and a passing sender-authentication check. Announcements always require moderation. Send plain text or .patch/.diff attachments: HTML, executable attachments and compressed archives are not accepted. Keep messages below 2 MiB and individual text parts below 512 KiB.

Pending posts and confirmed members awaiting posting-trust review appear in private daily moderator digests, only when there is work to resolve. Denial of posting trust leaves your subscription intact; a ban is separate. Announce posts still require individual moderation even after their author is vetted.

If a held post passes sender authentication, you receive an email explaining the hold and linking to a cancellation form. Opening the link changes nothing; confirm cancellation before the post is released. Release/rejection outcomes reply in the notification thread. A release means approved for delivery, not proof that every mailbox received it. Unauthenticated mail does not receive automatic notices to potentially forged addresses. Rejected SMTP submissions report their error directly to the sending mail system instead.

Published posts, including author addresses, are public and may be mirrored permanently. Subscriber membership is not published. Never send credentials, private keys or confidential material. Treat received patches as untrusted code.

Reading and searching without subscribing

• Web: hackers archive and announce archive, with threaded discussion.
• Search: use each archive’s search box. s:patch, f:author@example.org, and d:2026-01-01..2026-12-31 constrain subject, sender, and dates. See search syntax.
• Export: search results offer mbox.gz for matching messages or whole threads.
• Feeds: hackers Atom and announce Atom; searches also expose Atom feeds.
• NNTP: lists.solnix.io:119, groups io.solnix.hackers and io.solnix.announce; public read-only news access, unencrypted. No personal password is needed.
• Git: git clone https://lists.solnix.io/hackers/git/0.git hackers. Mirroring instructions describe keeping an offline copy. Public-inbox tools such as lei can search local imports.

IMAP and POP archive access

Both use implicit SSL/TLS and the lists.solnix.io certificate. Validate it; never supply personal mailbox credentials to these public readers.

IMAP: show all folders and choose io.solnix.hackers.0 or io.solnix.announce.0. History is split into 50,000-message folders (.0, .1, etc.); parent folders can appear empty. The server is read-only: no uploads, server-side flag changes, or archive deletions. Port 993 serves a different mail service on the shared IP; it does not serve these archives.

POP: generate a unique identifier once per client using uuidgen or python3 -c 'import uuid; print(uuid.uuid4())'. Keep it for later polls; it identifies your download cursor, and anyone who knows it can advance that cursor. Use separate accounts for the two lists. Without a suffix, POP presents the latest 1,000 messages; append .0, .1, etc. to the mailbox name for history.

POP deletions do not remove archive messages. The highest deleted message advances the cursor past earlier messages as well. The server advertises EXPIRE 0: retrieving messages may advance the cursor at QUIT even without explicit deletion. A client’s “leave messages on server” setting is therefore not a replay guarantee. Use a new UUID to redownload, or prefer IMAP/git when you want dependable historical browsing. These settings provide reading only, not an SMTP server or permission to post.

The GitGitGadget-style PR-to-patch bridge is planned, not deployed. Until then, send patches by email or use the Codeberg issue tracker.

How the community keeps costs sane

The binary cache is distributed peer-to-peer (over BitTorrent): using Solnix helps distribute it, so bandwidth scales with the community rather than with one origin. See The binary cache.