https://github.com/514-labs/dnsglobe

I developed Weather World because I wanted a simpler, more helpful way to stay ahead of the forecast. I truly believe that a weather app should be a tool that makes your life easier, not a source of distraction with ads and confusing menus.

How it helps you: The core of the app is all about visual clarity. I’ve focused on creating intuitive graphs that let you see temperature shifts and precipitation trends at a single glance. Instead of reading through long lists of numbers, you can visualize exactly how your day will unfold. It’s minimalist, lightweight, and built for speed—perfect for anyone who values a clean Android experience.

I’d love your support! Please give it a try and see if it helps your daily routine. If you find it useful, please recommend it to your friends! As a solo developer, your support and word-of-mouth are what help me improve and grow.

In compliance with the community rules, I’ve shared the link via IndieAppCircle. Check it out there and let me know what you think!

Find it here: https://play.google.com/store/apps/details?id=com.danie.pocasisveta

flow v0.1.1 is out

This release is mostly about making the UI work better in more environments while cleaning up a lot of rough edges.

New in this release:

• Added a new --mini mode that shows only the live graphs. Useful for smaller terminals.
• Press m to switch between Hero, Compact, Mini and Tiny views without restarting.
• The dashboard now automatically switches to a smaller layout if your terminal isn't tall enough.
• Refreshed the UI with cleaner borders, gradients and typography.
• Added a cleaner help dialog and status bar.
• Peak throughput now briefly flashes when a new session record is reached.

--tiny also got a pretty big overhaul.

It no longer depends on Bubble Tea or terminal detection, so it now works properly inside tmux #( ), cron jobs, pipes and redirected output. --tiny --no-color now produces plain text with no ANSI escape sequences.

Also fixed:

• Daily totals not resetting correctly across month/year boundaries.
• Hangs when network counter reads failed.
• Config file creation on macOS and Windows.
• Platform-specific config paths on Linux, macOS and Windows.

If flow has been useful to you, consider sponsoring the project. It helps me dedicate more time to maintaining it and building new features.

A GitHub star, bug report, or even sharing the project is just as appreciated.

https://github.com/programmersd21/flow

https://github.com/sponsors/programmersd21

I got tired of network monitors that look like they were designed for a BBS, so I built flow. It's a real time bandwidth monitor with Braille grid waveforms, spring smoothed numbers, and glowing borders that react to traffic load.

What it does

It shows live download and upload throughput with units that auto scale from B/s up to GB/s. The waveform is a high res Braille grid scrolling at 30fps, and the borders glow brighter as traffic picks up, going from a dark idle state to bright cyan and emerald under load. Numbers are spring interpolated so they glide instead of jumping around. It tracks session peaks, flashing white when you hit a new record, and keeps a running daily total.

There are three views that adapt to your terminal width. Hero is the full dashboard. Compact strips it down to numbers only. Tiny is a single line built for tmux status bars.

Philosophy

If a feature doesn't help you understand your network in under a second, it doesn't make the cut. No CPU panels, no packet counters, no multi pane clutter. Just download and upload throughput, done well.

Usage

flow                        # hero view, auto interface
flow --compact              # numbers only
flow --tiny                 # tmux status bar
flow --json                 # one-shot JSON for scripts
flow --once                 # one-shot plain text

tmux integration

set -g status-right "#(flow --tiny --no-color)"
set -g status-interval 1

Install

go install github.com/programmersd21/flow/cmd/flow@latest

or AUR:

yay -S flow-network-monitor-bin

or homebrew:

brew install programmersd21/flow/flow

Pre-built binaries for Linux, macOS, and Windows (amd64/arm64) are on the releases page.

It works with zero config out of the box. If you want to tweak the refresh rate, history length, or units, there's an optional TOML config at ~/.config/flow/config.toml.

Platform support

It runs on Linux (/proc/net/dev), macOS (sysctl), and Windows (GetIfTable2, no admin needed). Idle CPU stays under 1%.

Links

Source and demo: https://github.com/programmersd21/flow

---

Would love feedback, especially on the tiny/tmux mode. Curious if the info density is right for people running it in a status bar all day.

Hey everyone, just a brief update post on a project I'm working on. I posted about it previously here in this subreddit. I mainly added cross-platform support (Windows and macOS), standards (basically physical layouts, like how the Enter key is structured), and a feature for locking the keyboard render.

If you haven't seen the previous post and want more details, you can check out the repo.

TL;DR:

Ditto is a system-wide ASCII keyboard visualizer that mirrors your live keyboard inputs in real time, even when the terminal isn't in focus. It automatically syncs with your native terminal color scheme for a pretty neat and interactive eye candy.

Attached some sample layouts as well with different color schemes, to show how it would fit into a terminal multiplexer setup that has a code editor, active servers, test suite, etc. Perhaps you might like it :D

>

If you find this cool, I'd appreciate a star ⭐ :)

Hi! So Postman was eating 2gb of ram just to send a GET request, and Insomnia was forcing me into an account. Bruno was close to what I wanted, plain YAML files on disk, no account nonsense, but I live in the terminal and wanted something I could use without a mouse, so I built Noodle.

It is a TUI REST client. Requests are .yml files on disk. You browse collections in a sidebar, edit requests inline, swap environments at runtime, send them, and save changes back. No accounts. No telemetry. Just YAML files you can commit to git.

What works:

• Full request lifecycle, browse, edit, send, save
• Create, edit, delete and nest requests on folders
• Inline editing for url, headers, params, body. Keyboard-first, customizable keybindings at ~/.config/noodle/keybinds.yml
• Basic, Bearer, API Key built-in authentication
• Environment switching with $var substitution, cycle environments at runtime without restarting
• Send JSON body, multipart form data, URL-encoded, raw text, binary uploads
• OpenAPI 3.x and Postman importer (CLI only for now, UI is on the list)
• Tab to cycle focus between sidebar, request pane, response pane
• f1 pulls up a keybinding cheatsheet

Not there yet: pre/post scripts, assertions, runner, autocompletion, collection export and other features, but they are all on the roadmap.

Install:

curl -LsSf https://noodlerest.dev/install.sh | sh

Repo: github.com/wilfredinni/noodle

Docs: https://noodlerest.dev/docs/

Roadmap: https://noodlerest.dev/roadmap/

I built this for myself but figured others might want something similar. Feedback is greatly appreciated.

Edit: some errors on links and repeated features

AGY Builders,

We are all trying to build useful and scalable workflows for our AGY CLI and ecosystem, but the speed at which we need to learn, build, and deploy new things is incredibly overwhelming. If you are feeling that pressure, you are in the right place here at r/GoogleAntigravityCLI.

Over the past few weeks, I have been testing an "AGY WIKI OKF" setup that I put together myself (after inviting some members of this community to collaborate; mod is not proud). I know some folks might hesitate to trust a tutorial from a random Redditor, but I wanted to share this with the community anyway because it actually works.

I was able to build this because I am all-in on Google and the Antigravity Ecosystem. I’m a truly AGY—I am not some ultra-smart, 10x developer, but I know how to work hard, I dig for the right information, and I iterate.

AGY WIKI OKF | The Idea

To build a frictionless, token-efficient knowledge WIKI engine that transforms static documentation or notes (information) into an active, intelligent collaborator—orchestrated entirely by Antigravity CLI.

The core philosophy is simple: treat knowledge management as a clean pipeline and tokens as a premium, finite resource.

By anchoring this architecture to Google’s Antigravity CLI, the AGY WIKI OKF bypasses heavy middleware and complex UI layers, delivering a hyper-focused AI partner built entirely for execution speed, context hygiene, and minimal footprint.

Why adopting AGY WIKI OKF matters:

• Stay organized (AGY OCD): Structured Markdown and YAML keep the chaos in check.
• Save tokens: Doing more with less context window bloat.
• Scale shareable knowledge: Making it easy to pass context and logic between different LLMs.
• Humans and Agents working together: One standardized, readable format that works perfectly for both of us.
• BYOD (Bring Your Own Data): Own your context. Port it to the newest model, platform, or OS instantly.

The Tools

• Antigravity CLI
• Obsidian : The IDE for the Knowledge bank
• Obsidian Web Clipper:
  • Official Site
  • Chrome Web Store
  • Firefox Add-on

The WIKI

In the agent-first era, a WIKI is no longer just a static graveyard for human notes; it is the operational hard drive for your agents. By maintaining a highly structured WIKI, you ensure that every piece of context is stored in a clean, machine-readable format. This means that whether you are testing a new modular skill or spinning up a specialized agent, your AGY CLI knows exactly where to find the precise context it needs to generate autonomous action, moving you far beyond simple, reactive conversational text.

Reference: Gist on Knowledge Representation

Google Open Knowledge Format (OKF)

Google’s Open Knowledge Format (OKF) feels like the exact missing piece we've needed for orchestrating multiple AI agents effectively. It provides a vendor-neutral, interoperable standard for storing and sharing organizational knowledge.

Why this is huge for orchestration:

1. The "Lingua Franca" for Agents: Any agent can read it out of the box without platform-specific integrations.
2. Seamless Context Passing: Specialized agents can access, update, and pass the exact same foundational context back and forth.
3. Human-in-the-Loop Oversight: Because OKF is just Markdown and YAML, it’s inherently readable and auditable.
4. Scalable Knowledge: It acts as a shared, living library that grows alongside your agents.

AGY WIKI OKF Integration

Structuring an AGY Wiki using OKF revolutionizes how complex knowledge is shared. By standardizing documentation with concise Markdown and YAML frontmatter, OKF provides a unified taxonomy for cataloging AGY CLI slash commands or skills It is highly token-efficient, stripping away bloated formatting and maximizing context window limits.

The Prompt for Building an AGY WIKI OKF

AGY CLI WIKI OKF PROMT EXAMPLE

/grillme I want to initialize a brand-new, empty Obsidian vault from scratch that adheres strictly to the Open Knowledge Format (OKF) standard, with the specific intent of potentially open-sourcing or sharing this architecture later. I want a purely blank, skeletal framework with no pre-populated data. Please grill me to define the optimal architectural blueprint for this vault. I need you to interrogate me on: Do not generate the directory structure or files until you are satisfied that you have captured all my requirements for a production-ready, shareable knowledge base. 
Core Directory Hierarchy: How should we structure the root (e.g., /concepts, /resources, /indices, /log) to be intuitive for external users? Template Strategy: What base boilerplate templates do we need to ensure every new file is automatically OKF-compliant and structured for consistent metadata? Workflow Logic: Since this is a fresh start, what processes should we bake in for capturing information vs. refining knowledge that could be easily documented for others? CLI Integration: What specific file locations or configurations do we need to ensure this vault plays nicely with the Antigravity CLI from day one? Open-Source & Contributor Documentation: What files should we create to make this a "deployable" standard? Please include requirements for: A README.md with installation and usage instructions. A CONTRIBUTING.md that defines how to add new concepts or schemas. A "System Architecture" document that explains the logic behind the folder structure and metadata fields, ensuring anyone who clones this vault understands how to extend it.

The Final File Structure

AGY WIKI OKF
    ├── .agyrc
    ├── ARCHITECTURE.md
    ├── CONTRIBUTING.md
    ├── README.md
    ├── .agy
    │   └── .keep
    ├── .obsidian
    │   ├── app.json
    │   ├── appearance.json
    │   ├── core-plugins.json
    │   └── workspace.json
    ├── 00-Inbox
    │   └── .keep
    ├── 10-Projects
    │   └── .keep
    ├── 20-Areas
    │   └── .keep
    ├── 30-Resources
    │   ├── .keep
    │   └── Google Antigravity Documentation.md
    ├── 40-Archive
    │   └── .keep
    ├── 99-Meta
    │   └── Templates
    │       ├── Base_Template.md
    │       ├── Project_Template.md
    │       └── Resource_Template.md
    └── Clippings

TL;DR

• AGY WIKI OKF: Organizes your information (context) , AGY CLI commands, skills  behaviors, and A2A workflows into a token-efficient, shareable format that reduces inference costs for any LLM.
• Open Knowledge Format (OKF): Provides a standardized, vendor-neutral way to share context (Markdown + YAML), preventing platform lock-in and eliminating data fragmentation.

AGY Builders, I genuinely want your input on this. Please comment, grill me, roast me, ask questions, or give me your raw feedback on this AGY WIKI OKF setup. We are building the foundation to organize and share our data in the BYOD era. Let's build the future together.

https://github.com/vantroy/zigoku

I posted this at v0.1.3 a while back. The bottom line then was "feeds for shows discovering planned for v0.2": that shipped as Discover, plus a fair bit more since. Currently at v0.2.3.

For anyone new: a full-featured TUI for searching, browsing, and watching anime right in the terminal. Uses libvaxis for smooth rendering, Kitty graphics protocol for real cover art (half-block fallback elsewhere), SQLite persistence, and hands off playback to mpv.

New since v0.1.3:

- Discover: a ranked wall of popular anime (Daily / Weekly / Monthly / All-Time), real cover art, AniList scores/genres/season on each card; save a pick straight to the watchlist. This is what "planned for v0.2" turned into.

- Saner views keybinds: D for discover, H for history (watching), B for browse (search show by name), S for settings, plus minor tweaks. Old F keys still work just not announced

- Detail view carries a lot more metadata now: studio, per-episode runtime, source material (manga / light novel / original / …), a rating/popularity rank, a live airing countdown for currently-airing shows, and an origin marker for non-Japanese shows (donghua/aeni).

- Watchlist entries refresh themselves: open a show whose stored info has gone stale and it re-pulls fresh metadata in the background automatically, instead of leaving you looking at month-old data.

- Cover art is more reliable: WebP-served covers now decode correctly, and the last handful of blank-cover gaps are closed.

- Discover stays responsive under a bad connection: feed/metadata/cover fetches moved off the UI thread with wall-clock deadlines, so a slow or unresponsive server degrades instead of freezing the app.

- Configurable startup: open on History, Browse, or resume the last-watched show with the cursor already parked on the next episode.

- AUR PKGBUILD: a from-source package for Arch is in the repo now (makepkg -si); not on the registry yet since new-account registration's been closed since mid-June.

- Plus a pile of smaller stability fixes (quit no longer freezes with fetches in flight, Kitty ack bleed cleaned up on tmux/SSH, error states no longer bleed between views).

Still the same project, same goal - hands-on with Zig across networking, C interop, threads/channels, and TUI rendering all at once. Sharp edges are getting sanded down, but this is v0.2.3, not a finished product.

Hey!

I've been building vibez, a TUI Apple Music player for Linux and MacOS

v0.3.0 is out today!

Here's what changed:

Play Next

Press Shift+Tab on albums, artists, recommendations, or tracks to insert them right after the currently playing song.

Better queue management

You can now reorder the queue with Shift+↑/↓ (or **Ctrl+↑/↓**). The selection automatically follows the moved track, making queue editing much smoother.

Keyboard shortcut docs

The README and in-app help now document Tab (add to queue), Shift+Tab (play next), and Shift+↑/↓ (move in queue).

More reliable playback

Improved Widevine DRM support for headless playback and macOS, fixing playback issues and CONTENT_UNSUPPORTED/"no DRM" errors in Chrome-based streaming.

Better authentication

Expired Apple Music user tokens are now detected during startup and automatically trigger the re-authentication flow instead of leaving the player stuck on initialization.

Fixes

* Gracefully handle empty Apple Music libraries and Favorites (404 responses now return empty collections instead of failing).
* Fixed equalizer keyboard conflicts, so navigation keys no longer interfere with playback controls while the EQ panel is open.

Install, instructions and more: https://github.com/simonepelosi/vibez

Feedback and issues are very welcome. If you're enjoying vibez, a star on GitHub would mean a lot!

Today I'm sharing with you staze, a minimalist productivity terminal user interface that lets you start session, tag them and follow the amount of work you do, per-project. You can also export the data in .csv.

The cute plus, it hosts a cute little digital creature, named Staz, that lives as you work.

This is a learning project, so any feedback or suggestion would be very much appreciated!

Repo: https://github.com/SimonBure/staze

If you guys are "data-driven" workaholic like me, you can use staze to know how much time you've spent on your projects and start seeing how much you're really working. I'm must warn you, reality check was tough for me, turns out I'm not that efficient... 😆

Would you find it cool if the history section displayed multicolored bars (1 tag = 1 color)? Or maybe a settable theme for the app?

See you online!

Hey all, I built this interactive docker management TUI. I find it useful for quickly navigating volumes, logs, and images on my machine. Hopefully you enjoy it! Open source and instructions for running are in the README: https://github.com/yeet-src/container-explorer

Matcha is a terminal email client written in Go, built on Bubble Tea. After 40+ releases on the v0.x line, the first release candidate for v1.0.0 is out.

PGP encryption

Matcha can now encrypt and decrypt mail with PGP. A few details worth mentioning:

• Recipient keys are looked up automatically via WKD, so you usually don't need to import public keys by hand.
• It works with gpg-agent, so it fits into an existing GnuPG setup instead of managing keys its own way.

gitmail

If you use git format-patch / git send-email, Matcha can now apply a patch email directly to a local checkout. Patches are parsed and applied transactionally, confined to the target directory, without shelling out to git. This is an initial version, but if you follow patch-based mailing lists it's already useful.

Usability

Terminal mail clients tend to have a steep learning curve, and a lot of this release goes at that problem:

• Mouse support
• A command palette: one keybind, fuzzy-search every action, no need to memorize the keymap first
• A setup guide on first run that walks through features, mailto handling, and mouse setup
• Horizontal split-pane view, and the original message stays visible while you write a reply
• A grace period on delete/archive/move, so there's a window to undo before anything happens
• Jump to folder, a contact manager, and a macOS menu bar helper for notifications

Composer and rendering

• CC/BCC fields in the composer
• Emoji picker
• Syntax highlighting for code blocks in emails
• More HTML tags supported, with a cap on image rendering so large messages don't break the terminal
• Emails can be exported as HTML or Markdown

Plugins

The plugin system now has a proper marketplace, browsable in the TUI or on the web, with 35+ community plugins. Themes can be installed from the CLI and browsed from web, and plugins can now customize the UI itself. Submitting a plugin is one form away!

Providers

This release adds separate SMTP and IMAP logins.

Fixes

• Attachments no longer get dropped when sending
• Fixed the Gmail "555" error on send
• Fetching retries on flaky connections
• Better error messages
• Folder unread counters update correctly

Prebuilt binaries for Linux, macOS, and Windows (amd64 + arm64) are on the release page.

• Repo: https://github.com/floatpane/matcha
• Full changelog: https://github.com/floatpane/matcha/compare/v0.43.0...v1.0.0-rc1
• Discord: https://discord.gg/jVnYTeSPV8

Built a TUI wave editor / cutter for my own needs but why not share.
Goal is to achieve fast, keyboard driven editing of audio files. For now, only .wav are supported. standard BWF markers are supported and manipulated.

Used claude and my, hmm, expertise in digital audio. It's in Rust / ratatui but if your terminal supports kitty-graphics it will render waveform in actual pixels.

It's a WIP, i'm constantly improving it.

Here we go.

looking at changelog.md provides more insights into what it’s capable right now, i need to catch up on the readme

all the keyboard shortcuts are configurable via toml in your .config directory

Hey guys,

Just wanted to show off the current state of SDRtop, a terminal monitor I'm building for Software Defined Radio hardware. It now supports both the HackRF One and RTL-SDR platforms!
It's still in very early development

I’m a huge fan of thetop ecosystem (htop, btop, etc.), and since I couldn't find a dedicated terminal dashboard for radio hardware, I decided to build one from scratch using Rust and Ratatui.

The goal was to create a clean, non-bloated interface that gives you an immediate glance at what your SDR hardware is doing (frequencies, sample rates, gain stages, and internal states) without leaving the shell.

A few details:

• Written entirely in Rust.
• Supports both HackRF One and RTL-SDR.
• Fully responsive layout (as much as the widgets allow).
• Focuses on low resource overhead.

The project is currently at v0.3.5 and as I mentioned, it's in a highly experimental, early stage. If you have an SDR device or just love terminal dashboards, check it out! Feedback on the UI/UX or code structure is highly appreciated.

Repo: mustang6139/sdrtop: Terminal monitor for SDR hardware - written in Rust. Early development.

I've been working on HyprKit for the past few weeks ,a terminal-based Hyprland manager written in Python.

Current features include Monitor Manage and Waybar Manager

The goal is to make managing Hyprland easier without constantly editing config files.

It's still a work in progress, so I'd really appreciate feedback, ideas, or bug reports.

Im planning to add themes backup,startup apps and wallapapers in the future

If anyone wants to contribute, you're very welcome to join in!

GitHub: https://github.com/Kolgrim33/hyprkit