Planet for macOS: IPFS publishing with ENS identity

Planet's IPFS and ENS publishing boundary

Planet addresses a specific publishing problem: creating a static website without depending on a conventional centralized hosting service. Its intended users are authors who want to build blogs on a Mac, readers who follow decentralized sites, and people who already use ENS names as personal web identities. The README states that Planet can build a blog, publish it to IPFS, generate an IPNS value, and link that value to a website through an .eth name.

The project combines several technologies with different jobs. IPFS distributes content between peers. IPNS provides the mutable identity under which published content can be updated. ENS maps a human-readable Ethereum name, such as the examples shown in the README, to web content. Planet says that sites with an EIP-1577 content hash can be followed through ENS, while sites with RSS can also be read. That distinction matters because ENS compatibility is not the same as generic RSS support.

Planet does not eliminate operational work. Publishing still depends on IPFS behavior, the availability of content through gateways or peers, and correct handling of the IPNS key. The project's built-in local IPFS node and content pinning when following a site are designed to keep content accessible offline, but they do not turn a published site into conventional always-on hosting. The README does not document domain registration, gateway selection, publication retention, or recovery from a lost IPNS key. It does make key backup unusually visible, which is a better warning than leaving users to infer the identity risk from the technology.

Planet's local authoring and site-publishing flow

Planet's repository layout separates the native application, a CLI, CLI tests, and a lighter component named PlanetLite. The main app is described as a sandboxed native macOS application built with SwiftUI 3. From the repository alone, the exact internal service boundaries are not documented, so the most defensible architecture view comes from the stated features and top-level projects rather than guesses about individual classes.

For an author, the documented flow begins with Markdown editing and live preview. The template browser manages templates used to build the site. The generated site can publish to IPFS, and Planet can produce an IPNS value ready to serve as an EIP-1577 ENS content hash. Media does not need to be limited to images because the README says that video, audio, or any file format can be attached. Export and import provide a site-level transfer mechanism, while Export Planet can include the site's IPNS key.

For readers, Planet offers several content paths. A user can follow ENS sites that expose an EIP-1577 content hash, read RSS, Atom, or JSON Feed, pin followed content for offline use, and view NFT avatars as site icons when the resolved site supports that information. Posts can be starred or shared, and a global audio player handles attached audio. This is broader than a one-purpose static-site generator because the same application includes discovery and subscription features.

The WorldWideWeb integration provides an external preview path for sites built with Planet. Plausible.io integration is also listed, with the README linking an example domain, but it also states that the privacy policy applies to the app and that third-party analytics or tracking services are not used. The documentation therefore does not fully explain the operational boundary between the app, self-hosted content, gateways, ENS resolution, and Plausible.io. Site owners should not infer from the feature list that a particular analytics deployment is configured automatically.

Building Planet from source on macOS

Planet is free and open source under the MIT license, but the README does not give Homebrew, Mac App Store, or direct application-download installation instructions. Its stated setup route for contributors is to clone or obtain the repository, install Git LFS, and use the referenced external build instructions. The commands below are the only complete setup commands reproduced by the README.

Install Git LFS with Homebrew:

brew install git-lfs

After entering the project directory, activate Git LFS for that repository:

git lfs install

The README warns that Kubo binaries will be only 133 bytes on disk when Git LFS has not been activated correctly. GitHub Desktop is presented as an alternative checkout method because it has built-in Git LFS support. If using it, confirm that large-file content has been fetched before opening the project.

The repository contains `Planet.xcodeproj/`. For a local build configuration, the README says to create `local.xcconfig` beside `Planet.xcodeproj/Planet.xcconfig` and then override the relevant settings. The documented feature configuration is:

PLANET_ENABLE_APPLE_INTELLIGENCE = YES
PLANET_ENABLE_AI_CHAT_SCROLL_MANAGEMENT = NO

Before signing, overwrite or add the applicable values in `local.xcconfig`. `DEVELOPMENT_TEAM` is the setting most directly tied to local code signing, while the README also lists `CODE_SIGN_STYLE` and `ORGANIZATION_IDENTIFIER_PREFIX`. The Apple Intelligence feature requires a macOS 26 SDK at build time and macOS 26 or later at runtime when enabled.

The README does not document a first-run sequence for creating a site, assigning an IPNS key, or publishing through ENS. Its build instructions are hosted separately at the address beginning `https://planetable.eth.limo/build-instructions/`. A first real site therefore cannot be reconstructed from the README alone, and this limitation should be checked before selecting Planet as a publishing tool.

Backups and upgrades for Planet site identities

The clearest maintenance guidance in the README is not about dependency upgrades but about protecting Planet data. The project describes itself as being at an early stage and warns that many changes happen. It advises backing up data regularly, with special emphasis on the IPNS key. An exported Planet package can include that key, which makes export a potentially sensitive operation rather than routine housekeeping.

A site owner needs to understand the difference between exported content and an export that includes the identity key. The README confirms that Export Planet includes the IPNS key, but it does not document encryption, key reformatting, partial export, conflict handling, or whether an import restores key material automatically. Consequently, users should not assume that every export has the same recovery properties. The stated boundary is that users should perform a backup and verify that the relevant IPNS key is present before relying on it.

Upgrade cost is visible in several forms. The repository includes a native app, `PlanetCLI`, `PlanetCLITests`, `PlanetLite`, build settings, hooks, and Git LFS-managed binaries. A local developer may therefore need Xcode, Git LFS, signing configuration, and enough storage to retrieve binary assets. The README also mentions `git-hooks/pre-commit.sh`, which synchronizes the build number with the Git commit count. This adds repository-specific build behavior that a contributor should inspect before installing hooks or changing the checkout's Git configuration.

Release history provides dated evidence of recent work: `release-0.22.6` was published on 2026-10-08, with insider builds on 2026-10-07 and 2026-10-05. The repository is not archived, and its last push was on 2026-10-08. These facts do not establish migration compatibility between releases. The README contains no changelog, upgrade guide, database migration policy, or list of breaking configuration changes. Because sites can depend on an IPNS identity, app upgrades and data migrations deserve separate verification.

Planet's sandboxing and trust boundaries

Planet states that it runs entirely in a sandbox and cannot access data outside that sandbox unless explicitly granted. The application also says its development team collects no information from it and that the app does not use third-party analytics or tracking services. Those are project policy claims, not an independent audit, and the README does not provide a detailed data-flow inventory.

The sandbox claim is particularly relevant because Planet manages local content, templates, subscriptions, media, and potentially an IPNS key. It also embeds a local IPFS node and can follow external websites. The repository's feature list therefore spans local storage, network retrieval, decentralized identity, file attachments, optional external preview, and optional traffic analytics. Those are different trust boundaries even when they appear in one desktop interface.

IPFS and ENS should not be treated as interchangeable. IPFS addresses content, IPNS allows a name to point to changing content, and ENS supplies a .eth naming layer. Planet says it can generate an IPNS value for EIP-1577, but the README does not document the signing method, key custody behavior, supported wallets, or recovery procedure. Those omissions matter more than ordinary publishing settings because ownership of the key affects who can update the name.

The README's listed sites demonstrate that Planet can present decentralized sites, including .eth.limo addresses, but examples do not establish availability guarantees. Peers, gateways, DNS resolution, and the site owner all affect whether a visitor sees current content. Offline pinning addresses local access to followed content, yet the documentation does not state how pinned data is stored, how large a site may become, or whether publication automatically pins every asset. Planet is best evaluated as an authoring and subscription client with decentralized distribution, not as a replacement for every hosting requirement.

Planet versus IPFS CLI publishing and RSS readers

The main alternative is a separate workflow built around Kubo and an RSS reader. Kubo is present conceptually through Planet's built-in local IPFS node and Git LFS-managed Kubo binaries, while the repository also includes `PlanetCLI`. A direct approach would use command-line tooling to publish static files to IPFS, publish an IPNS record, and separately configure an EIP-1577 ENS content hash. Readers could then use an RSS, Atom, or JSON Feed reader. The README does not document those command-line publishing commands, so they should not be presented as part of Planet's documented interface.

The difference is scope. A separate toolchain can divide publishing, naming, preview, and reading among focused components. Planet puts those tasks in one sandboxed macOS app and adds templates, Markdown live preview, media attachments, feed subscriptions, pinning, NFT avatars, sharing, audio playback, import and export, and decentralized-site following. That convenience is most useful to someone who wants a desktop workflow rather than assembling the publishing path.

The tradeoff is control and documented depth. The README exposes Planet's feature set well, but it links out for complete build instructions and does not document the low-level publication sequence, ENS signing, gateway behavior, or CLI syntax. A separate command-line workflow may expose more operational detail, although that cannot be claimed from this repository alone. Planet's advantage is the integrated interface; its risk is that important identity and upgrade details are not included in the main README.

Editorial conclusion

Planet fits authors and readers who already have a reason to publish or follow static content through IPFS and ENS. It is less suitable for users who need a documented installer, Windows or Linux support, or a production hosting service. Before adoption, verify the external build instructions, confirm that the required Kubo assets were fetched through Git LFS, and test export and restoration of the IPNS key before entrusting a site identity to the app.

Frequently asked questions

Official sources

1. License: MIT
2. Planetable/Planet on GitHub
3. Project website
4. README
5. Releases