iBoard is a little practicing project, figuring out how Elixir-development and AI comes together. So, I recently wrote this Blog-server. The content here doesn’t really matter! The project is not public (yet) but will be published at GitHub once it fulfills some basic quality standards ;-)

The iBoard Project This web application is written in Elixir with Phoenix, LiveView, TailwindCSS, DaisyUI, Ecto/Postgres, to name the most important.

ExDocs

↣ Documentation

The full dependency list reads like:

:bcrypt_elixir, "~> 3.0"
:phoenix, "~> 1.8.3"
:phoenix_ecto, "~> 4.5"
:ecto_sql, "~> 3.13"
:postgrex, ">= 0.0.0"
:phoenix_html, "~> 4.1"
:phoenix_live_reload, "~> 1.2", only: :dev
:phoenix_live_view, "~> 1.1.0"
:lazy_html, ">= 0.1.0", only: :test
:phoenix_live_dashboard, "~> 0.8.3"
:esbuild, "~> 0.10", runtime: Mix.env() == :dev
:tailwind, "~> 0.3", runtime: Mix.env() == :dev
:heroicons, github: "tailwindlabs/heroicons", tag: "v2.2.0"
:gen_smtp, "~> 1.2"
:swoosh, "~> 1.5"
:castore, "~> 1.0"
:req, "~> 0.5"
:telemetry_metrics, "~> 1.0"
:telemetry_poller, "~> 1.0"
:gettext, "~> 1.0"
:gettext_sigils, "~> 0.1.0"
:jason, "~> 1.2"
:dns_cluster, "~> 0.2.0"
:bandit, "~> 1.5"
:tzdata, "~> 1.1"
:boundary, "~> 0.10", runtime: false
:ex_doc, "~> 0.31", only: [:dev, :prod], runtime: false
:earmark, "~> 1.4"

With a big hug to this gorgeous community!

Follow the tag #iboard if you’re interested in the faith of this project.

Features so far (Buzzwords)

• Accounts, Users (phx.gen.auth)
• Posts, Drafts, Authors, Moderators, Likes, Followers
• User management, invite by e-mail
• Supports DaisyUI Themes
• Supports Locale and Timezone

More Transparency: The New Audit Log

Starting today, the blog keeps an audit log — a complete, human-readable record of what happens on the platform. From “Andreas created the post ‘Welcome!’” to “Hannah liked your post,” every meaningful action is captured and stays traceable.

Two Views

• My Activity (/activity): Every signed-in user sees their own timeline — everything you did, or that concerns you (your account, your posts).
• Audit Log (/admin/audit-log): Administrators see the complete timeline for the entire platform.

Both views update live: new entries appear automatically, no refresh needed. With infinite scrolling and a full-text search across action, person, and subject, you’ll quickly find what you’re after — even in long histories.

Reads or Writes — Your Call

Every entry is tagged as a read or a write. Opening a post, profile, or group counts as a read; everything else counts as a write. The All / Writes / Reads toggle lets you show exactly what matters to you — the total count and live updates follow your selection.

Sessions at a Glance

Sign-ins are part of the timeline too: a guest visit is recorded as “New session from <IP> (<country>),” and logins and logouts as “logged in” and “session ended.” The IP, country, and session ID live in the entry’s metadata.

Since these can pile up fast, there’s a Hide sessions switch: one click and the pure session entries drop out of the list, the count, and the live updates — keeping your focus on the events that actually matter.

Server Restarts, Made Visible

When the server restarts, it writes its own entry: “The server started.” Unlike the other entries, this one is visible to all signed-in users. So you can see at a glance whether and when there was an update or a restart.

Why Bother?

Transparency builds trust. The audit log makes it clear who did what and when — both for you personally and for the people running the platform. No more guesswork, no black box.

Enjoy exploring your timeline!

Until now, a post here could be public, private, or sent as a direct message. That covered the extremes — everyone, or just one person — but not the middle ground most of us actually live in: this handful of people, and no one else.

Groups fill that gap.

Create a group in seconds

Head to My Groups in the sidebar (or /groups) and hit New group. Give it a name, and start adding people:

• Friends are added instantly — they’re active right away.
• Anyone else gets an email invitation. Once they confirm, they join the group and become a mutual friend, so the connection works both ways.

Posts for members only

When you write a post, visibility now has a Specific Groups option. Pick which groups may read it — and, separately, which of those may comment. Only active members of a listed group can see or reply.

Every group-restricted post carries a “Who can read this” section, so it’s always clear exactly who’s in the room. No guessing, no accidental oversharing.

It lands in the inbox

Published group posts show up in each member’s inbox (/dm) right alongside direct messages, complete with a Group badge and per-person read/unread tracking — the same unread counter you already know from the navbar. Nobody misses what’s meant for them.

A home for every group

Each group has its own page (/groups/:id) listing its members and how many posts each has published. Any active member can invite new people; you can remove anyone you added and leave whenever you like; and the owner can manage everyone.

Groups are yours to shape — start one today and share with just the right circle.

With the rise of modern AI tools, the concept of generating complete, gapless documentation for an entire codebase seems tempting at first glance. It appears to be the ultimate solution: every function, variable, and logic branch automatically explained. However, upon closer inspection, this approach reveals significant downsides.

No seasoned developer would voluntarily document every single detail—and for good reason. If every line of code were commented, the famous mantra “Read the fucking code” (RTFC) would lose its validity. Yet, RTFC remains entirely justified, especially when dealing with low-level details. Often, the code itself is the most precise description of what is happening at the machine level.

Documentation intended for users—whether other developers or DevOps engineers—should not attempt to include everything. Such “completeness” dilutes the critical information. Readers are forced to wade through a mountain of trivial details to find the actual architectural decisions or usage patterns. This is frustrating, time-consuming, and ultimately leads to the documentation being ignored because the signal gets lost in the noise. Good documentation curates knowledge; it does not merely duplicate it.

Small open-source projects, often sustained by only a handful of contributors, are facing a critical turning point. Historically, these initiatives thrived on the necessity of collaboration and code sharing. However, Artificial Intelligence is fundamentally altering this dynamic. Developers can now generate complex features, bug fixes, and even entire modules using AI assistants alone, removing the dependency on external help or peer reviews.

Yet, this surge in efficiency carries a paradoxical risk: the motivation to share work publicly is diminishing. If every developer can complete their “private closed work” autonomously without relying on the community, the ecosystem risks fragmentation. Instead of refining a shared open solution together, we may see the rise of isolated, AI-generated silos. The thesis is not that open source will vanish, but that the foundation of small, purely community-driven projects is eroding because the barrier to autonomous development is lowering while the incentive for openness fades.