securitylab_nJuly 13, 2026🇷🇺Translated from Russian

Tired of Instant Messaging, Users Flock to Virtual Pigeons: Roost App Revives Postal Delivery with Birds and Animals

Users press the send button, yet the recipient receives nothing for seconds or even minutes. Instead, a virtual bird appears on screen, picks up the letter, and flies across a real-world map toward the addressee. The journey can last several hours or even days. This built-in delay is not a server error but the central feature of the Roost messenger, which has rapidly gained popularity across social networks.

Before sending a message, Roost lets users choose their courier. A falcon travels faster than a hummingbird, while more relaxed users can entrust their letter to a snail or a turtle. The base speed is tied to the real capabilities of the chosen animal, so delivery time depends on both the courier and the distance between correspondents. The route is shown on a map, and the application provides an estimated arrival time in advance.

Birds can be trained in mini-games to gradually increase their speed, and every flight grants experience points. There is no hard speed cap, allowing a favorite pigeon to eventually outpace other creatures in a user’s virtual aviary. The app features more than one thousand birds and animals that users can collect, upgrade, name, and describe.

Core Features and Social Mechanics

Roost blends messaging, social networking, and a collection game. There is no traditional news feed or endless scrolling. Users add friends by name, create group chats called “nests,” and exchange messages with anonymous correspondents via the Pen Pals function. Each nest holds up to 11 participants, and a separate bird must fly to every member. According to GamesBeat, shortly after launch the app saw more than 100,000 active conversations daily.

Creator Background and Explosive Growth

Roost was developed by Logan Mendelson, who works as a product manager for trust and safety at Ticketmaster. The project began as a small experiment for friends. Mendelson first shared the concept on TikTok, and the public version launched at the end of April. The developer had not planned to turn the pigeon-themed diversion into a large social platform.

The real surge began after a post by Karen Lewis on Threads (owned by Meta Platforms Inc.). She described how her daughter and friends communicate in Roost using English from the time of Elizabeth I, with friends replying in the same style. The post received approximately 147,000 views and turned the little-known app into a viral phenomenon.

Within three days the user base grew from 10,000 to 100,000. After roughly five weeks the number approached 300,000 and then surpassed that figure. The creator states that in less than two months Roost attracted more than 300,000 users. A friend of the developer also reported that birds now deliver over one million messages per week and have collectively flown more than one billion virtual miles.

Monetization and Technical Controversies

Mendelson spent nothing on advertising. Users organically shared videos, screenshots, and invitations. The developer has not yet raised external funding and plans to sustain the service through in-app purchases. Core functions remain free, while the app sells rare birds, a subscription with extra features, and lifetime founder-club status.

The first controversy has already emerged: Mendelson used AI-generated bird images, prompting criticism from parts of the community. He acknowledged the concerns and launched a contest for artists to replace the generated illustrations with original artwork. During development he also used Claude Code and believes that without AI assistance it would have been extremely difficult for one person to maintain a service of this scale.

Privacy and Data Handling Concerns

Beneath the charming surface lie significant privacy limitations. Roost requests precise coordinates because geolocation is required to calculate routes and flight times. Users can choose to show friends their exact location, only the city, or hide the endpoint entirely. However, flight direction can still reveal the approximate district of both sender and recipient.

Conversations are not protected by end-to-end encryption. The privacy policy explicitly states that messages are stored in plaintext and remain accessible to server systems. Data transmission is protected by TLS and server storage uses Google Cloud encryption, yet employees and automated systems can technically read message content. Texts from messages, profiles, and anonymous letters are also sent to OpenAI for automated moderation, although the developer claims that names, emails, and account identifiers are not transmitted alongside the text.

Registration requires an Apple or Google account, a phone number, date of birth, and location permission. Current rules allow Roost only for users over 18, an interesting restriction given that many publications portray the service as a new teenage trend.

Availability and Philosophy

Roost is available on iPhone and Android. The iOS version requires iOS 18 or newer, supports only English, and is distributed free with in-app purchases. On Google Play the app has already exceeded 100,000 installations.

The creator describes Roost as a “slow social network.” While conventional messengers compete on instant delivery and capture attention with notifications, Roost sells the experience of waiting. The recipient is not ignoring the message, causing anxiety, or showing a “read” status. The pigeon simply has not arrived yet.

Related articles

HabrOther

OAuth Authorization Server Built Without Storing User Profiles

The article details the evolution of an OAuth Authorization Server that deliberately avoids storing user profiles, relying instead on external identity providers for authentication. It addresses three core constraints: hundreds of dynamically created isolated APIs, a public SPA client without a BFF, and the inability of resources to query the AS on every request. The design separates concerns so the AS handles only clients, tenants, grants, audiences, scopes, keys, sessions, and token issuance while the Main API owns profiles and roles. Tokens are managed securely inside a Service Worker using a custom FedCM grant, eliminating races across tabs and reducing XSS exposure. The approach minimizes blast radius, simplifies compliance, and keeps the AS replaceable without affecting product domain logic.

HabrOther

Why a 202-Character License Key Uses ECDSA P-256 Instead of Ed25519 or RSA

A developer building offline license verification for a .NET desktop application evaluated Ed25519, RSA, and ECDSA P-256 before selecting the last option. The decision was driven by the requirement for zero external dependencies, keys short enough for manual entry from email, and support for key rotation without breaking existing licenses. Although Ed25519 offers faster verification and a smaller public key, it is absent from System.Security.Cryptography in both .NET 8 and .NET 10, with API approval only targeted for version 11. RSA-2048 produces signatures too long for practical use, resulting in a 571-character Base32 string that users would find cumbersome. ECDSA P-256 with SHA-256 delivers a fixed 64-byte signature that becomes a manageable 202-character key when encoded in Base32, while remaining fully available in the runtime. The article also covers performance measurements, the risks of ECDSA nonce generation, and the deliberate choice of the IEEE P1363 signature format to guarantee fixed-length output.

HabrOther

Pilcrow Publishes Free Comprehensive Guide on Web Authentication

Author Pilcrow has released a detailed, ad-free handbook covering authentication and authorization practices for web applications. The resource draws on personal experience and includes practical examples in JavaScript and Go. It examines password-based methods, email verification, multi-factor authentication, passwordless flows, and passkeys while highlighting associated risks and usability trade-offs. The book also provides in-depth guidance on session management, token security, expiration policies, and email address handling as account identifiers. Recommendations emphasize choosing methods that match application security requirements and user expectations. Additional context is given on OWASP resources and community support channels.

HabrOther

redb 3.4.0 Adds Replay Checkpoints, Shared Runtime Layer and Declarative Secrets Handling for .NET Ecosystem

redb 3.4.0 delivers operational improvements for the .NET integration platform that includes typed storage over Postgres, MSSQL and SQLite, the redb.Route engine modeled after Apache Camel, the Tsak runtime with dashboard and clustering, and redb.Identity for OIDC and OAuth 2.1. The release focuses on post-deployment resilience with replay checkpoints that capture message state at named points inside routes, allowing safe re-execution of downstream steps without duplicating side effects. A shared runtime layer moves framework assemblies into a separate Libs/shared directory so that individual DLLs can be replaced without rebuilding or redeploying the entire Tsak or Identity packages. Secrets are now declared with a [Sensitive] attribute on endpoint options, ensuring URIs containing passwords or keys are sanitized before they reach logs, metrics or health checks. Additional controls include role-based access to management APIs, persistent audit trails and cryptographic signing of dynamically loaded modules. All Pro features remain free on the entire 3.x line with no licensing server required.