Dev Null News██████╗ ███████╗██╗ ██╗ ███╗ ██╗██╗ ██╗██╗ ██╗ ███╗ ██╗███████╗██╗ ██╗███████╗ ██╔══██╗██╔════╝██║ ██║ ████╗ ██║██║ ██║██║ ██║ ████╗ ██║██╔════╝██║ ██║██╔════╝ ██║ ██║█████╗ ██║ ██║ ██╔██╗ ██║██║ ██║██║ ██║ ██╔██╗ ██║█████╗ ██║ █╗ ██║███████╗ ██║ ██║██╔══╝ ╚██╗ ██╔╝ ██║╚██╗██║██║ ██║██║ ██║ ██║╚██╗██║██╔══╝ ██║███╗██║╚════██║ ██████╔╝███████╗ ╚████╔╝ ██║ ╚████║╚██████╔╝███████╗███████╗ ██║ ╚████║███████╗╚███╔███╔╝███████║ ╚═════╝ ╚══════╝ ╚═══╝ ╚═╝ ╚═══╝ ╚═════╝ ╚══════╝╚══════╝ ╚═╝ ╚═══╝╚══════╝ ╚══╝╚══╝ ╚══════╝██████╗ ███████╗██╗ ██╗ ██╔══██╗██╔════╝██║ ██║ ██║ ██║█████╗ ██║ ██║ ██║ ██║██╔══╝ ╚██╗ ██╔╝ ██████╔╝███████╗ ╚████╔╝ ╚═════╝ ╚══════╝ ╚═══╝ ███╗ ██╗██╗ ██╗██╗ ██╗ ████╗ ██║██║ ██║██║ ██║ ██╔██╗ ██║██║ ██║██║ ██║ ██║╚██╗██║██║ ██║██║ ██║ ██║ ╚████║╚██████╔╝███████╗███████╗ ╚═╝ ╚═══╝ ╚═════╝ ╚══════╝╚══════╝ ███╗ ██╗███████╗██╗ ██╗███████╗ ████╗ ██║██╔════╝██║ ██║██╔════╝ ██╔██╗ ██║█████╗ ██║ █╗ ██║███████╗ ██║╚██╗██║██╔══╝ ██║███╗██║╚════██║ ██║ ╚████║███████╗╚███╔███╔╝███████║ ╚═╝ ╚═══╝╚══════╝ ╚══╝╚══╝ ╚══════╝

Open Settings, then Remotes, and the alert list has grown to three switches. Below On-site notifications, which is on, sits Off-site notifications, which is off, and Notification sound. Flip the new one, say yes to the browser's permission prompt, and close the tab. Ten seconds after someone messages you, a quiet banner appears. It reads, "/dev/null · Remotes. You have a new message in Remotes." Click it and you land in your Remotes inbox.

Credit goes to the contributor who wired a real push pipeline behind that switch. Every new unread message queues one delivery per recipient. Each delivery is held 10 seconds and rechecked before it leaves. The message must still be in the conversation, still unread, not muted, not blocking the sender, and Remotes must still be on. Only then does the server sign an empty request and hand it to the browser's push service, so Google, Mozilla and Apple never see a word of the message. Each account can enroll 20 browsers or installed apps. The 21st is refused with a plain error, and a lock stops two tabs from racing past the limit. Failed sends retry three times, and the banner names no sender and shows no preview.

There is one catch. The switch needs your browser's shared locks, the mechanism that keeps two tabs from enrolling at once. Where those are missing, the Off-site switch sits greyed out. On a phone or tablet, you must add /dev/null to your Home Screen and enable it from the installed app. A plain Safari tab never gets the option.

You land on a profile you don't know and, right under the follower counts, a small row of avatars appears with a sentence. The sentence names two handles you recognise, then says how many others you follow who follow this person too. The handles open those profiles. The avatars, and the count, open the whole list, which also gets its own tab between Followers and Following, shortened to "You know" on phones. You have to be signed in and looking at someone else to see any of it.

Credit ashkesarmaa, who crossed the profile's followers with the people you follow, using the follow records already there, with no new table or migration. The preview fetches three, shows three little avatars, but names only the two with the most followers. The sentence counts every one of them. The list comes 30 at a time, each row with its own Follow button.

One catch. The profile names the best-followed, but the list behind it runs newest follow of that profile first, like the Followers tab. The handle you just read may sit pages down among the 30-at-a-time rows, so click through expecting a different order.

You hit the search key, type bug, and there it is above the results under Actions. The action is Report a bug. Press Enter and the composer opens already in bug mode, ready to file the issue. Type co and no action appears. Type comm and Write a commit takes the top slot instead.

Credit goes to simonhamp, who taught search to do five things as well as find them. You can write a commit, request a feature, report a bug, go live, and end a stream. The matcher needs three letters and only fires while your search is the start of one of its words, so "commits about caching" stays a search. A bare slash offers the same /feature and /bug commands as the composer. Go live gives you a stream link box and a slider from 1 to 12 hours, preset to 2. Signed-in people only. The developer pickers in chat leave all this out.

One catch. Come in through bug or feature and the header over the box still reads "Write a commit", even though the box is set to open an issue.

Open any developer's profile and click README, the third tab beside Commits and Replies, and their GitHub profile page appears without leaving the site. Headings, badges, tables, centered banners and all come through. Links open in a new tab. Nothing is fetched from GitHub until you ask for that tab.

Credit goes to hbenabdallah, who taught profiles to read the repository GitHub names after the developer. The server asks GitHub for the rendered page, then runs it through a fixed list of tags. Scripts, styles, classes and ids go. Images survive only from five GitHub-owned hosts, and links must be http, https or mailto. One fetch is kept for a day, or four minutes when the README holds uploaded images whose signed links expire. A GitHub timeout is remembered for five minutes so an outage does not hammer the API.

One catch. If someone opens your README tab while you have no README, the server remembers "no README" for a full day, so the one you add this morning may not appear until tomorrow. Errors clear in five minutes. An empty profile does not.

You've got a bug to report. Type /bug in the commit box, which turns your draft into a bug report, paste the steps, hit send, and instead of a GitHub error toast you get the amber hourglass. You're in timeout. Here's the reason, and here's how long is left. Your draft stays put, still an issue, ready for another try.

Credit goes to sulimanbenhalim, who put bug and feature drafts behind the same lock as replies and remote messages. The server checks your timeout before it checks the 10-issues-a-day limit, and turns you away with the reason and the time remaining, rounded up to the minute, or to the whole hour once more than a day is left. Open ten issues in a day and you still hit the old wall.

One catch. That dialog is shared with replies and remotes, and its wording hasn't caught up. It tells you that you can't commit, reply, or send remotes, and never mentions issues. You get the right reason and the right countdown, but you have to infer that bug reports are on the list too.

You type a commit, flip to the preview, and the long GitLab URL you pasted comes back as the tan GitLab mark and the merge request numbered 42 in gitlab-org/gitlab. Do the same with Codeberg and a pull request reads forgejo/forgejo#42, icon and all.

Credit goes to zangetsu02, who replaced the lone GitHub matcher with a small table of forges. Each row holds the host, owner rule, item paths, the mark written before the number, and an icon. Three forges sit in it now. They are GitHub, GitLab and Codeberg, each with its own list of reserved first paths (7 for GitLab, 12 for Codeberg) so explore/projects and user/login stay ordinary links. Owner and repository names run to 100 characters on the two new forges, item numbers to 10 digits with no leading zero, and GitHub's existing tests pass unchanged.

The catch is that it matches on domain alone. A GitLab project inside a subgroup, like group/subgroup/project, stays a bare URL, and so does anything on a self-hosted Forgejo or Gitea server, because the code has no way to tell those apart from the host name.

You sign a request and ask for six names. Back come three to put on screen and three spares, each with a follower count, the number of people you follow who follow them, and a flag saying whether they follow you. Dismiss one and a spare slides up in its place. Nobody in the list is followed yet.

Credit goes to Taldres, who wired signed requests to the same suggestion engine the web runs. It mixes people your follows already follow with a popular pool drawn from the 20 most-followed accounts, and only ever suggests someone who has posted a top-level commit. The picks hold steady all day, seeded from your account id and the date, then reshuffle tomorrow. Turn the round number for the next page. Past the last page it loops.

Ask beside a profile and that developer's follows come first. Ask beside a commit and the thread's other posters do. Send both and you get a 422, and a commit you can't see answers "That commit is no longer available." Muted and blocked people stay out.

One catch. Marking someone not interested is a one-way door. The call returns 204 and they never appear again, but there is no call to undo it and no list of who you dismissed.

Open a profile, click Followers, and look along the tab strip. Beside Followers and Following there's a new one called Mutuals. Click it and you get the familiar list, avatar, name, handle, a line of bio, and a Follow button on every row, but only for people that profile follows who also follow it. When there's nobody, the empty state deadpans "Fatal. No mutuals yet."

Credit goes to kachelle, who built the list from the follow records the site already keeps. Take everyone the profile follows, keep only those with a follow pointing back, and hand back 30 per page as you scroll. Each row knows whether you follow that person, so the button is right. Guests can browse it too. Across a block in either direction, the page is simply not found.

One catch. The sort runs on when the profile followed each person, not when each one followed back, so a mutual who returned the favour this morning can sit far below someone they followed last week.

You paste a pull request link into a commit and hit preview. Back comes the owner/repo shorthand, octocat in front, the number where your eye expects it, no ellipsis.

Credit jubianchi, who taught the linkifier to walk GitHub's paths one segment at a time instead of matching the whole URL at once. Commits and releases read as the repo plus an at-sign and a short hash or tag. Commit hashes get cut to seven characters whether you paste seven or all 40. Comparisons show the two branch names with three dots between them, and a comment or review marker adds a word after the number. Profiles drop the repository and leave just the octocat and taylorotwell.

Files and folders are the freshest trick. A link into a file becomes the repo name, a colon, the file's own name, and a line range. A folder becomes the repo name, a colon, and the folder's last name with a slash. The branch and full path stay in the link's title and are read aloud to screen readers. The full URL also stays in the text, invisible but copyable. Forty-eight of GitHub's own pages, from dashboard to pricing, stay URLs so they aren't mistaken for accounts.

One catch. When a branch name holds a slash, as in feature/login, a file or folder link hands that branch to the path reader anyway. The folder comes out named after the last segment instead of its real name, though the link still lands in the right place.

Three messages land while you're away, all in the same chat. You come back, glance at the sidebar, and the unread badge has moved by one. Open the inbox and that conversation's row still reads 3 ahead, but the count on the Remotes header reads 1. Nothing in settings changed. The badge simply stopped counting messages.

Credit goes to kachelle, who taught the count to count conversations. The server now tallies distinct conversations holding unread messages instead of every message, so each chat adds at most one. Two friends write in, three notes from one and two from the other, and the badge shows 2 instead of 5. Waiting requests still ride along in the same number, and the dock rechecks every 15 seconds, or every 6 with a thread open, subtracting the chat you're already reading.

There is a catch. Rows and badge now speak different languages. A row still totals messages, so one chat can announce 8 ahead while the badge says 1, and pending requests can push the badge above the number of unread chats. When the two numbers disagree, the badge is the one counting conversations.

Open the app for the first time since the update and it asks you to accept the terms and privacy policy. Tick the box and the server writes down the moment you did. Come back later and it stops asking, because the account it hands to the app now carries the date you agreed and a plain yes-or-no for whether that counts.

Credit goes to shanerbaner82, who wired the tick to the database and rewrote the fine print for Apple's reviewers. The version in force is a single moment, 25 October 2026 at midnight UTC, and the server accepts only that exact one. Send any other and it answers with a 422, so an old build cannot agree to wording it never displayed. The sign-in call can carry the version too, and every answer about the signed-in user now reports the version, your acceptance date, and whether you are current. The published terms gained zero tolerance for abusive users, Report, Mute and Block, action on reports within 24 hours, bans that survive an Apple sign-in, and the usual Apple clauses.

There is one catch. This is a record, not a gate. Nothing on the web or in the API checks your acceptance before letting you post, and the web sign-in page still has no checkbox. Everyone already on the service starts with a blank date, so the app asks them once.

Open an org thread and a thin strip rides over the top of the messages. It holds a pin, a count in mono type, and the name and first line of the newest pin. Press it and a panel drops down with all of them, newest first, each with its author and time.

Credit simonhamp, who gave every message a pinned time and taught the thread to read it. The list comes back newest first, a maintainer can keep 25 at once, and the count is checked again after the org is locked, so two maintainers grabbing the last slot can't make 26. The loser just sees the pin refused. Pin an old message and it opens to everyone in the org, history or not. Images load, voice notes play, reactions and replies work.

Long pins stop at three lines in the panel, with a Show more button. The first pin asks "Pin for the whole org?" and won't ask again once you tick the box. The app gets matching pin and unpin calls, though it has no buttons for them yet.

One catch. A member whose history starts after a pinned message can react to it while it stays pinned. Unpin it and the message leaves their view, but the reaction they left stays behind with no way to take it back.

Open the scheduled commits page and every waiting row now carries a Commit now button beside a small trash can that replaced the old Cancel button. Hover the can and a tooltip says Cancel. Press Commit now and the button locks and reads "Committing…", then the row settles into Submitted for review with its body still in place, and the rest of the list keeps its order.

Credit goes to kachelle, who gave the scheduler a manual override. The button sends a commit through the usual review process ahead of time, and the body, poll, images and link preview all travel with it, landing as a pending commit like any other. Under the hood, one conditional update claims the row only if it is unsubmitted, uncanceled, and its author is neither timed out nor banned. The work runs in a transaction retried five times, so a double press cannot make two commits. The list still refreshes every 30 seconds, and you can hold up to 10 schedules at once, up to 30 days out.

One catch. Commit now spends from the same budget of 10 commits a minute as ordinary posting, so on a busy minute the button answers with a "Slow down" toast and your commit goes back to waiting for its scheduled hour.

You click unsubscribe on Monday's admin note and get back to work. Tuesday's copy of that same note, queued before you clicked, never shows up. No bounce, no apology, no filter rule to write. The queued email looks at your account and stands down.

Credit goes to Akiyo974, who made each queued admin email check its recipient once more at delivery. Admin mail leaves in batches of 500, one job per person, carrying only a user id, so the address and unsubscribe link are rebuilt when the job runs. Akiyo974 added a look at that freshly loaded record. If the unsubscribe or ban timestamp is set, the job returns before the mailer sees it. A test email addressed by hand still goes through. Each job gets three tries, with 60- and 600-second backoffs between them.

There is one catch. The confirmation you see after sending counts everyone the audience picked when you hit the button, not everyone who actually receives it. Opt out afterward and you still sit in that number, while the skipped job finishes quietly and reports success.

You open Growth and leave the dates at their default 30 days. Below the funnel, past the daily charts, a new panel lays out a tile for each device type Fathom reports. Those are usually phone, desktop and tablet. It then adds one for all devices. Ordered by visitors, busiest first, each tile gives a rate to one decimal and the raw counts behind it, so you can see how many signups came from how many visitors.

Credit goes to mnapoli, who taught the funnel to ask Fathom for device totals. It requests the unique people behind the visit event and the signup event, grouped by device, then divides one by the other for each device. Fathom's answers sit in a five-minute cache, and the all-devices tile still comes from the funnel's overall rate.

One catch. A signup is filed under the device it happened on, not the device the person visited from. Read on a phone and sign up on a laptop, and your visit stays in the phone column while your signup lands in the desktop column. Phones then look worse at converting than they are, and desktops look better.

You sign in with GitHub for the first time, click through setup, and land on the follow step. Above the usual suggestions sits a hairline card stamped imported from github.com/yourhandle. Two big mono numbers tick up from zero while little avatars pop in one at a time, each ringed in its own lane color, five faces and a +4 for the rest. The heading no longer says "Follow a few developers." It says you already follow nine.

Credit goes to mnapoli, who taught the step to show the import's work. The page checks back every 1.5 seconds while the import runs right after sign-in, and stops after 15 seconds if it never lands. A follow counts as imported if it was made in the ten seconds before the import stamped its finish time. The welcome bot is filtered out. Followers get their own number and their own faces, and the suggestions reload once the import lands so you aren't offered people you already follow.

One catch. The row for people you follow on GitHub who aren't here yet, with its copy-an-invite button and X post, isn't wired to anything. Pending follows aren't stored, so that count is zero everywhere except local development, where it comes from a number you type into the URL. Everyone else sees the faces and no invite.

Open /dev/null on your phone while signed out and, a moment after the page settles, a card slides up over the tab bar. It reads "you're reading /dev/null" above "Only developers post here," then lists three things. Every account is a GitHub account, you start out following the people you already follow on GitHub, and posts are commits of plain text about what you're building. A full-width Join with GitHub button sits where your thumb already is.

Credit goes to mnapoli, who built the sheet into the app's shared layout, so every page carries it. Three bullet lines, one button 48 pixels tall, a 300-millisecond slide up, and a shadow to lift it off the feed. It hides itself at 768 pixels and wider, and ducks out of the way while the keyboard is open.

One catch. The ✕ only silences the sheet for the tab you are in. Open a fresh tab and it slides up again, and if your browser blocks per-tab storage, it comes back on every single page.