Otávio C.

Triton

2026-01-22T12:47:23Z

Statuslog
PURLs
Web Page
Now Page
Weblog
Pics
Pastebin

A couple of months ago, I wrote about Triton, detailing some of the technical decisions I made during its development. That post covered architecture, design patterns, and lessons learned along the way. At the time, Triton was ready to launch, but I needed extra time to review its code one more time to ensure everything worked exactly as intended.

A month has passed, and Triton is now available for download. Not only that, its source code is also available on GitHub.

For those unfamiliar, omg.lol is a web service¹ that provides a collection of fun, useful tools like status updates, permanent URLs, web pages, weblogs, pastebin, and more, all tied to a personal address. I built Triton to bring these to the desktop with a native macOS experience, allowing users to interact with all these services from a single, unified application.

The app supports multiple omg.lol addresses, letting users switch between them seamlessly. Beyond basic functionality, Triton includes quality-of-life features like local muting (hiding specific addresses or keywords from the statuslog timeline), sharing through native macOS share sheets, context menus for quickly copying URLs in various formats, and integration with Spotlight and Shortcuts.

Triton is free and will always be free and open source. No in-app purchases, no prompts to rate or review. If you find it useful and want to support its development, I'd appreciate a coffee to keep the code flowing ☕️.

Now, to the features!

Statuslog

Statuslog serves as the landing screen of the application. Even before logging in, you can browse the list of posts published by the omg.lol community.

Interaction with posts happens through right-click actions. A contextual menu appears with options to open the post in a browser, copy the URL, or mute all posts from that user².

After logging in, you can publish a status using the compose button in the top right corner of the app.

The compose window is resizable, and I built an emoji picker from scratch for this application. macOS doesn't provide an emoji picker that can be used programmatically in the way I needed, so creating a custom solution was necessary.

If you have multiple addresses, you can use the address picker at the top of the compose window to select which address to post from. This pattern appears throughout other features of the application as well.

PURLs

Permanent URLs, or simply PURLs, can be created from the plus button in the top right corner of the application. Once a PURL is saved, right-clicking reveals several options: copy the URL, copy it as a Markdown link, open in browser, share using macOS' native sharing menu, or share directly on Statuslog, which opens a compose window with the PURL and its name already populated.

Web Page

Every omg.lol address has a landing page called Web Page. This page works as an index for all the services, websites, and links a person might want to share.

In Triton, you can edit the content of your Web Page. The application maintains a local copy of previous versions, allowing you to revert changes if needed.

Double-clicking a version opens the editor, while right-clicking also provides access to editing options.

From the top bar, you can open the current Web Page version in a browser and share a link via Statuslog.

Now Page

Now Page is a simple page where you can share information about what you're up to; an easy way to consolidate what you're doing, reading, watching, playing, and more to share with friends and family.

On Triton, this feature mirrors the Web Page implementation, with a local copy of recent changes and buttons to open in a browser and share directly via Statuslog. There’s also a button to open the garden with other Now Pages from the omg.lol community.

Weblog

Weblog is where new blog entries can be created and managed. New entries can be created using the plus button in the top bar, which opens a composer window. From the composer, you can set the date and time of publishing, as well as the post status or visibility.

For those using tags to group entries together, the Tags field autocompletes previously used tags. Pressing TAB selects the first matching tag, streamlining the tagging workflow.

And Weblog is where other features meet. You can upload photos to some.pics via Pics and add them to blog posts as Markdown images. Similarly, code snippets from Pastebin can be copied as code blocks and inserted directly into blog entries. Blog posts can also be shared directly to Statuslog. This integration makes the workflow seamless; everything needed to publish a complete blog post is accessible from within the application.

Pics

Pics is my favorite feature. It handles image uploads to some.pics, allowing you to add captions, alt text, and tags to images during the upload process.

Photos can be added from the Photos app library or by dragging and dropping images directly into the photo uploader. This flexibility makes it easy to work with images regardless of where they're stored.

Already uploaded pictures can be edited to update their captions, alt text, and tags. This makes it easy to refine how images are presented without needing to re-upload them.

The contextual menu provides several options for working with images. You can copy the some.pics link to a photo, copy it as a Markdown link, copy it as a Markdown image, and much more. Images can also be shared directly to Statuslog. These options simplify the process of incorporating images into blog posts, status updates, or any other content being created.

Pastebin

Pastebin is a place for short text and code snippets to be shared with others online. Like other features in Triton, it provides a contextual menu with several options, including the ability to copy snippets as Markdown code blocks for use in blog posts or entries, and to share directly to Statuslog. This makes it straightforward to share code examples or text snippets while maintaining proper formatting.

That’s Triton. If you have feature requests or run into any issues, the GitHub repository is the place to go. I'm looking forward to seeing how people use the app.

And better yet, omg.lol was created and is maintained by Adam, a genuinely good person who stands for the right causes and created one of the most welcoming communities on the web.
Muting users and keywords can also be configured from Triton Settings.

Defaults in December 2025

2026-01-08T10:49:34Z

Continuing the tradition from the last two years (2023, 2024), it's time for my annual Defaults post.

As I always do at some point during the year, I migrated back to Apple Reminders for my personal to-dos. The reason is simple: it's well integrated with the system, easy to share with family members, and Apple keeps adding new features every time there's a new version of its operating systems. It's not as beautiful as Things, but it gets the job done.

Without going through the photos in my library, I can't pinpoint when I started using the Leica LUX app. But during the course of the year, it took Halide's place on my phone and is one of the icons on my Lock Screen (the other being Apple's Camera app). Leica LUX is not cheap, but the quality of the photos is phenomenal. For portrait photos, there's nothing like it. Best of all, the subscription can be shared with family members, which is great.

For about four years, I worked at a VPN company, but earlier this year I switched companies and stopped using their product. I'm using ProtonVPN now and am pretty happy with their service. I just wish their Apple TV app was a little bit faster at fetching and updating the list of countries and servers.

In the past, I canceled my Git Tower subscription, but this year it's back on the list of apps I use daily. It's one of the applications that's always open on my computer, so it's definitely worth its price.

Two other apps that are always open on my computer are Proxyman and Kaleidoscope. The combo of Tower, Proxyman, and Kaleidoscope works as a productivity booster. They're always open, next to Terminal and Xcode.

Finally, the complete list of defaults apps in December 2025:

📨 Mail Client: Mail.app, Proton Mail
📮 Mail Server: iCloud, Proton Mail
📝 Notes: Notes.app, iA Writer
✅ To-Do: Reminders.app
📷 iPhone Photo Shooting: Camera.app, Leica LUX
🟦 Photo Management: Photos.app
📆 Calendar: Calendar.app
📁 Cloud File Storage: iCloud Drive
📖 RSS: Feedbin with Reeder
🙍🏻‍♂️ Contacts: Contacts.app
🌐 Browser: Safari.app, Orion
💬 Chat: Messages.app, Signal
🔖 Bookmarks: Anybox
📑 Read It Later: GoodLinks
📰 News: Feedbin, Mastodon
🎵 Music: Music.app
🎤 Podcasts: Podcasts.app
🔐 Password Management: 1Password, iCloud Keychain

Other:

🔎 Search: Kagi Extension (in Safari.app)
💬 Social: Ivory (Mastodon), Tapestry
📝 Journaling: Journal.app
📚 Reading: Kindle, Books.app
🔑 VPN: ProtonVPN
🔢 MFA: Yubico Authenticator

Coding:

🧑‍💻 Code Editor: NeoVim, Xcode (macOS), Nova
👨‍💻 Git: Tower
👨‍💻 Proxy: Proxyman
👨‍💻 Diff: Kaleidoscope
👨‍💻 Shell: Zsh
👨‍💻 Multiplexer: tmux

Subscriptions in December 2025

2026-01-08T10:49:00Z

Similar to the tradition of publishing the annual list of Defaults, this is the review of my current subscriptions. I’ve also published the lists in 2023 and 2024.

Event though I have a Bear lifetime subscription, I moved my blog to Pika. I don’t know exactly why, but I like it. Also, the folks from Good Enough, the makers of Pika, are super transparent and responsive on Mastodon.

I’ve also moved to a lifetime subscription in omg.lol because that’s the best corner of the web. I even made my own application, Triton¹, to use omg.lol services natively from my computer.

And to simplify my life and cross-post everything to Mastodon, I’ve added EchoFeed to my list of subscriptions. It’s the kinda of service that works so well you don’t even remember it exists.

Finally, the complete list of subscriptions in December 2025:

Streaming

Amazon Prime - 90 €/year
Apple TV+ (as part of the Apple One subscription)
Disney Plus - 160 €/year

Podcasts

99% Invisible + other SiriusXM Podcasts - 50.00 €/year
Twenty Thousand Hertz+ - 45.00 €/year

Services

Must-Have

1Password - $60/year
Apple One - 35 €/month
Arq - $59.99/year
Firefox Relay - 12 €/year
Kagi - $108/year
Proton - 95 €/year (190 € every two years, actually).

These are indispensable to me.

Blog/Social

Pika - $60/year
omg.lol - $0/year (lifetime)
EchoFeed - $20/year ($25/year, but the omg.lol community gets a discount)

These are the best online communities one could hope for.

Reading

Feedbin - $50/year
GoodLinks - 6 €/year

Fun to Have

Nintendo Switch Online + Erweiterungspaket - 40 €/year

Apps

Ivory - 30 €/year
Git Tower - 99 €/year
Kaleidoscope - $8/month
Proxyman - $99 (Perpetual License with 1 year of updates)

Hey, send me a coffee if you like it 😉

Lessons from Building Triton

2025-11-15T21:01:00Z

Modularity with Swift Package Manager
One-Way Dependencies
Vertical Slices
Protocol-First Boundaries
Modern Swift Throughout
Data Flow: DTOs to Domain Models
Streaming-Based Caching
Dependency Injection
Pure SwiftUI
Features Built on This Architecture
Consequences and Tradeoffs
Conclusion

I've been building Triton, a native macOS client for omg.lol. For those unfamiliar, omg.lol is an amazing web service¹ that provides a collection of fun, useful tools like status updates, permanent URLs, web pages, weblogs, pastebin, and more, all tied to a personal address.

Triton brings these to the desktop with a native macOS experience. Users can post status updates, manage their PURLs (permanent URLs), edit their web pages and now pages, write weblog entries, upload pictures to some.pics, and manage code snippets in the pastebin; all from a single, unified application. The app supports multiple omg.lol addresses, letting users switch between them.

Beyond basic functionality, Triton includes quality-of-life features like local muting (hide specific addresses or keywords from your statuslog timeline), sharing through native macOS share sheets and statuslog posts, context menus for quickly copying URLs in various formats (plain URLs, Markdown links, or Markdown code blocks), and Spotlight and Shortcuts integration.

Triton isn't available for download yet, but I'm planning to release it soon. When it launches, it will be open source and available on GitHub as well, allowing others to read its code, contribute to, or adapt it for their own needs.

Once Triton is released, I'll write a proper introduction covering the app from a user perspective; its features and workflows. For now, though, I want to focus on how the application was built and the architectural decisions behind it. Like the source code itself, these decisions are documented as Architecture Decision Records (ADRs) and will be available on GitHub, providing context for anyone interested in understanding or adapting the architecture.

Building a macOS application from scratch, or any application to be honest, presents an opportunity to define architectural patterns that will serve the project for years to come. Rather than starting with a monolithic structure and refactoring later, I chose to implement a modular, feature-isolated, layered architecture from day one using Swift Package Manager.

Modularity with Swift Package Manager

The architecture centers on isolated packages within a Packages/ directory. Each package represents either a feature domain or an infrastructure concern, creating boundaries that are enforced by the compiler.

Packages/
├── Status/               # Feature: Status updates
├── PURLs/                # Feature: URL management
├── Account/              # Feature: User account
├── ...                   # Feature: ...
├── OMGAPI/               # Infrastructure: API client
├── DesignSystem/         # Infrastructure: UI components
├── SessionService/       # Infrastructure: Session management
├── ...                   # Infrastructure: ...
└── FoundationExtensions/ # Utilities

Swift Package Manager enforces dependency relationships at compile time. A feature package cannot accidentally import another feature's internal implementation. It's impossible to violate this without explicitly modifying Package.swift files.

Currently, the application has 19 packages in the Packages/ directory, not counting external dependencies like MicroClient and MicroContainer (which I created as well). These 19 packages contain more than 50 modules (targets), with each feature typically splitting into targets representing different architectural layers. This might seem excessive at first, but the granular structure provides precise control over dependencies and enables isolation between concerns.

The impact is felt immediately. Xcode rebuilds only changed packages and their dependents, improving incremental build times. More importantly, the architecture accommodates growth without major changes.

One-Way Dependencies

Within this modular foundation, I established strict architectural layers with enforced one-way dependency flow:

         Views
           |
       View Models
           |
      Repositories
           |
  Network & Persistence Services
           |
    Shared Services (OMGAPI, SessionService)
           |
Foundation Modules (Utilities)

These layers are enforced through Swift Package Manager's dependency system. Feature packages implement their layers as separate targets, while infrastructure and utility packages occupy the lower layers. The compiler prevents any upward dependencies.

Views and View Models depend on Repository protocols, never directly on Network Service or Persistence Service. This isolation enables testing at each layer independently. A View Model test uses a mock repository without touching network or persistence code. A Repository test uses mock services without real API calls or database operations.

The Repository layer coordinates between Network Service and Persistence Service, implementing domain logic and caching strategies. This is where the application decides when to fetch from the network versus reading from local storage, how to handle conflicts, and when to invalidate caches.

Vertical Slices

Each feature package implements a complete vertical slice through all architectural layers:

Status/
├── Package.swift
├── Sources/
│   ├── Status/                    # Main UI and integration
│   │   ├── Views/
│   │   ├── Scenes/
│   │   └── Factories/
│   ├── StatusRepository/          # Data coordination
│   ├── StatusNetworkService/      # API communication
│   └── StatusPersistenceService/  # Local storage
└── Tests/

Features expose themselves through a standardized App Factory pattern:

public final class StatusAppFactory {
    private let environment: StatusEnvironment

    public init(
        sessionService: any SessionServiceProtocol,
        authSessionService: any AuthSessionServiceProtocol,
        networkClient: NetworkClientProtocol
    ) {
        environment = .init(
            sessionService: sessionService,
            authSessionService: authSessionService,
            networkClient: networkClient
        )
    }

    @MainActor
    @ViewBuilder
    public func makeAppView() -> some View {
        let viewModel = environment.viewModelFactory
            .makeStatusAppViewModel()

        StatusApp(viewModel: viewModel)
            .environment(\.viewModelFactory, environment.viewModelFactory)
            .modelContainer(environment.modelContainer)
    }

    @MainActor
    public func makeScene() -> some Scene {
        ComposeStatusScene(environment: environment)
    }
}

Everything else, Views, View Models, Repositories, Services, remains internal to the package. Features cannot access each other's internals, enforcing true isolation.

I built Triton alone, but on a team, this structure promotes shared ownership. Any engineer can work on any feature without needing to understand the entire codebase. The boundaries are clear, the contracts are explicit, and the architecture naturally guides correct implementation.

Protocol-First Boundaries

At layer boundaries, I use protocols to define contracts. Each repository and service has a public protocol marked Sendable for concurrency safety:

public protocol PURLsRepositoryProtocol: Sendable {
    var purlsContainer: ModelContainer { get }

    func fetchPURLs() async throws
    func addPURL(address: String, name: String, url: String) async throws
    func deletePURL(address: String, name: String) async throws
}

Implementations are actor types, providing automatic serialization and thread safety:

actor PURLsRepository: PURLsRepositoryProtocol {
    private let networkService: any PURLsNetworkServiceProtocol
    private let persistenceService: any PURLsPersistenceServiceProtocol
    
    // Implementation details...
}

One feature I like in Xcode is that I only need to document protocols. When opening the Quick Help to read a method's documentation, Xcode displays the protocol's documentation if that method comes from a protocol the type implements. This means I document public protocols, the contracts defining what each layer provides. while implementation details remain undocumented and internal, reducing maintenance burden when internals change. When the code is released on GitHub, all public protocols will be fully documented.

Since protocols are public but implementations are internal, concrete types are built and made available to other layers through factory methods. Each service and repository module includes factories that create and return instances:

func makeRepository() -> any PURLsRepositoryProtocol {
    PURLsRepository(
        networkService: makeNetworkService(),
        persistenceService: makePersistenceService(),
        authSessionService: authSessionService,
        sessionService: sessionService
    )
}

This pattern ensures consumers depend on protocol contracts while factories handle the creation of concrete implementations, maintaining encapsulation throughout the architecture.

Modern Swift Throughout

The architecture leverages modern Swift features at every layer:

Concurrency: Actors for services and repositories ensure thread safety without manual locks. All async operations use async/await.
Observation: View Models use @Observable instead of ObservableObject, eliminating boilerplate and improving performance through fine-grained observation.
Swift Data: All persistence uses Swift Data with @Model types, avoiding Core Data's complexity for straightforward data models.
Type Safety: Type safety everywhere. E.g., in the network layer, NetworkRequest<Request, Response> provides compile-time safety for API calls. DTOs in the OMGAPI package define API contracts explicitly.

Data Flow: DTOs to Domain Models

Data flows through distinct representations at each layer:

Network API
    ↓
DTOs (OMGAPI package) ← Codable, API-shaped
    ↓
Repository ← Maps to domain/persistence models
    ↓
Domain Models (@Model or structs)
    ↓
ViewModels / Views

The OMGAPI package contains all request and response DTOs, matching the API structure exactly. Network Services return these DTOs unchanged. Repositories map DTOs to domain models or persistence models, applying business logic during transformation.

This decoupling means API changes don't ripple through all layers. The repository acts as an anti-corruption layer, translating between the external API contract and internal domain representation.

Streaming-Based Caching

Repositories coordinate data synchronization through AsyncStream patterns:

actor PURLsRepository: PURLsRepositoryProtocol {
    private func startPURLsSync() {
        streamTask = Task { [weak self] in
            guard let self else { return }

            for await purls in networkService.purlsStream() {
                let storablePurls = purls.map { purlResponse in
                    StorablePURL(address: current, purlResponse: purlResponse)
                }
                try await persistenceService.storePURLs(purls: storablePurls)
            }
        }
    }
}

Network operations emit data through streams. Repositories listen and automatically persist incoming data. Views query Swift Data directly using @Query, receiving updates automatically through SwiftData's observation.

This pattern provides automatic synchronization with minimal manual coordination. Data flows naturally from network through repositories to local storage and UI, with the repository managing the stream lifecycle.

Dependency Injection

Feature integration happens through a lightweight dependency injection container. The main application's TritonEnvironment registers infrastructure and App Factory factories:

struct TritonEnvironment: TritonEnvironmentProtocol {
    private let container = DependencyContainer()

    var statusAppFactory: StatusAppFactory { container.resolve() }

    init() {
        container.register(
            type: StatusAppFactory.self,
            allocation: .static
        ) { container in
            StatusAppFactory(
                sessionService: container.resolve(),
                authSessionService: container.resolve(),
                networkClient: container.resolve()
            )
        }
    }
}

The container supports .static allocation for singletons and passes itself to factory closures for resolving dependencies. Type-safe resolution through container.resolve() catches missing registrations at compile time.

Internally, each feature has its own environment which registers the services and repositories that belong to that feature. The feature's AppFactory receives infrastructure dependencies from the main application's container and uses them to initialize the feature's environment.

It's worth noting that infrastructure services like Session Service, Auth Session Service, and Network Client follow a specific module pattern. Features depend only on protocol-defining interface modules; for example, a feature imports SessionServiceInterface but never SessionService directly. Only the main application links against modules containing concrete implementations. This separation ensures features remain decoupled from infrastructure implementation details, depending solely on contracts.

Pure SwiftUI

The entire UI is SwiftUI. No AppKit or UIKit² anywhere. A Design System package provides shared components: view modifiers, toolbar items, colors, and spacing constants. Features compose from these building blocks, ensuring consistency across the application.

SwiftUI Previews enable rapid development. I use the Mother Object pattern to create fixtures:

enum StatusViewModelMother {
    @MainActor
    static func makeStatusViewModel(
        statuses: [Status] = StatusMother.makeStatuses(),
        isLoading: Bool = false
    ) -> StatusViewModel {
        .init(
            statuses: statuses,
            isLoading: isLoading,
            repository: StatusRepositoryMother.makeRepository()
        )
    }
}

These Mother Objects serve double duty: SwiftUI Previews during development and test fixtures for unit tests. Ninety percent of views have multiple preview states, catching UI issues immediately.

#Preview("Not Loading") {
    StatusView(
        viewModel: StatusViewModelMother.makeStatusViewModel()
    )
    .frame(width: 420)
}

#Preview("Loading") {
    StatusView(
        viewModel: StatusViewModelMother.makeStatusViewModel(
            isLoading: true
        )
    )
    .frame(width: 420)
}

Features Built on This Architecture

The architecture's true test comes from the features it supports. Triton implements a complete suite of omg.lol services, each as an isolated feature package:

Statuslog provides a timeline of status updates with local muting capabilities. Users can mute specific addresses or keywords, useful for avoiding spoilers or filtering unwanted content.
PURLs manages permanent URLs. Users create, edit, and delete PURLs, with context menus for copying URLs in various formats (plain URLs or Markdown links) and sharing via the native share sheet or directly to Statuslog.
Web Page and Now Page features let users view and edit their omg.lol pages directly from the app. Changes publish instantly, eliminating the need to use a web browser for content updates.
Weblog offers full-featured blog management. Users write new posts, edit existing entries, and delete old content. Each entry has a context menu with sharing options and the ability to open posts in a browser.
Pics integrates with some.pics for image management. Users upload new pictures, delete existing ones, and share photos through various formats—Some Pics URLs, direct image URLs, or Markdown image syntax.
Pastebin handles code snippets and text pastes. Users create new pastes with syntax highlighting support, edit existing snippets, and share public pastes through context menus. Private pastes remain accessible only within the app.

The architecture supports multiple omg.lol addresses. Users switch between addresses without friction, with each feature respecting the currently selected address. Session management and authentication happen through the Auth Session infrastructure package.

Consequences and Tradeoffs

This architecture requires upfront planning before writing feature code. Creating a new feature means setting up package structure, defining protocols, and implementing layers sequentially. There's more initial overhead than throwing everything in a single target.

But the benefits justify this cost. The architecture prevents common problems:

Circular dependencies: Impossible due to SPM's acyclic dependency enforcement
Tight coupling: Layer boundaries and feature isolation prevent accidental coupling
Difficult testing: Protocol boundaries enable mock implementations at every layer
Architectural erosion: Compiler enforces the architecture continuously

Parallel development becomes straightforward. As I mentioned above, I built Triton alone, but in a larger codebase with multiple engineers, they can work on different features without conflicts because features don't share code. When features need common functionality, it must be explicitly extracted to infrastructure packages, making shared dependencies visible and intentional.

And the modular structure scales naturally. Adding a new feature follows established patterns. The architecture accommodates growth without major restructuring because the boundaries were established from the beginning.

Conclusion

Building a modular, feature-isolated, layered architecture from day one establishes patterns that serve the project long-term. Swift Package Manager enforces boundaries at compile time. Strict layering with one-way dependencies prevents coupling.

Modern Swift features like actors, async/await, @Observable, and Swift Data work naturally within this structure. The protocol-first approach at boundaries enables testing while keeping implementation details private. Streaming-based caching provides automatic synchronization with minimal coordination code.

The architecture isn't free. It requires initial setup and ongoing discipline. But it prevents common problems before they occur and scales naturally as the codebase grows. For a project intended to last years, this investment pays off.

I'm looking forward to releasing the application. I'm currently reviewing the documentation and the ADRs, and have to prepare, sign, and notarize a build to publish on GitHub. Hopefully soon.

And better yet, omg.lol was created and is maintained by Adam, a genuinely good person who stands for the right causes and created one of the most welcoming communities on the web.
The application compiles for iOS and iPadOS as well, but I still have to refactor the UI to look better on these systems.