CraysFreeFrom
FreeFrom is a phone-first Nostr social app that promises privacy, no email signup, public and private channels, encrypted chats, voice and video calls, zaps and cross-client ownership. The interesting part is underneath: keys, relays, app-store rules, Japanese operator details, and a real security advisory history to understand before importing an important identity.
A phone app built around Nostr identity
FreeFrom is a mobile social app that tries to make Nostr feel like a normal phone network while keeping the protocol's stranger account model in the background. The store listings describe a simple registration flow with no email address, phone number or ordinary social login. The official site talks about posts, pictures, short videos, public and private channels, encrypted direct messages, calls and ownership of the relationships a user builds. That is the promise: use a familiar social app, but do not create a platform account that only the platform can recognize.
The key difference is that FreeFrom sits on Nostr. A FreeFrom account is not mainly a database row with a password reset link. It is a Nostr keypair that can sign events, identify a public profile, follow people through a graph other clients can read and publish content through relays. This is why the app can say that a user's content and social relationships can also be accessed from other Nostr products. The identity is portable because the protocol is portable, not because FreeFrom runs a magical export button.
That also explains why FreeFrom needs a more careful read than a normal app-store listing. A one-click signup is convenient, but the thing created by that click is a private key. A public channel looks like a group chat, but it depends on relay delivery and app interpretation. An encrypted DM sounds private, but Nostr chat security has changed over time. A zap looks like a tip, but it touches Lightning-style payment rails. FreeFrom is approachable on the surface and very Nostr-shaped underneath.
The public project surface in 2026
FreeFrom's current public footprint is split across the official website, Apple App Store, Google Play, a direct Android APK link, GitBook documentation, NostrApps, social accounts and vulnerability databases. The Apple listing names `FreeFrom - the nostr client`, identifies FreeFrom K.K. as the seller, shows version 1.6.2, lists a January 16, 2025 current-version release date, and keeps the app in Social Networking with a 17+ rating. The listing also shows a long set of supported languages, which fits the app's attempt to be a global consumer client rather than a narrow developer tool.
Google Play shows the Android package as `com.freefrom`, with FreeFrom K.K. as developer, a Teen content rating, a January 6, 2025 update date, 10K+ downloads and the same core positioning around privacy, no email or phone number, Nostr-based ownership, encrypted DMs, public channels, no system ads and spam detection. AppBrain, which tracks Android listings, adds a useful historical note: it records version 1.6.2, roughly 18 thousand downloads, a 70.5 MB APK and says the app was removed from Google Play on March 31, 2026. Google Play itself still rendered a page during this research, so a reader should check the store in their own country before assuming installation availability.
The official site is broader than the store copy. It presents FreeFrom as a decentralized social network, highlights private groups, public channels, calls, cross-platform compatibility, end-to-end encrypted chats, data ownership and an ad-free experience. It also links to the App Store, Google Play, a direct APK file, a web debug tool and GitBook documentation. Those links matter because FreeFrom is not only a brand name in an ecosystem map. It is an actual app surface with multiple distribution paths, support channels and documentation that expose how the project wants to be used.
Who operates it and why that matters
The operator named across public sources is FreeFrom K.K., a Japanese company. Apple identifies FreeFrom K.K. as the seller and developer. Google Play lists FREEFROM K.K. as the developer and exposes a support email plus a Japanese address in Chuo-ku, Tokyo. The FreeFrom terms page identifies the operator as FreeFrom K.K. and gives a Japanese company registration number and contact route. That legal surface is useful because a Nostr client can be decentralized in protocol terms while still being a normal app business with support, app-store obligations, privacy claims, moderation tools, security response and local legal jurisdiction.
Signup without email is not the same as no risk
FreeFrom's onboarding pitch is simple: one-click registration without email, phone number or other personal information. That is a meaningful difference from conventional social apps. It reduces the amount of account-recovery and identity data a user is asked to hand over before posting. It also makes the first run less bureaucratic. The app can create a usable Nostr identity and let the user begin posting without asking for a phone number that can later be used as a tracking handle or lockout point.
The tradeoff is that the private key becomes the account's center of gravity. FreeFrom's own FAQ says the public key is the account ID, while the private key is the only certificate that can access the account. It warns that the private key cannot be recovered or changed and should not be shared. That is not a small footnote. It is the real account model. If a user loses the private key, the identity cannot be restored by support. If a user exposes the private key, another person can impersonate the account at the protocol layer.
This makes FreeFrom a good app to try with a fresh key first. A new user can learn posts, follows, channels, DMs, zaps and relays without putting their main Nostr identity at risk. A user who already has a valuable public identity should pause before importing an nsec into any mobile app. The question is not whether FreeFrom is malicious. The question is whether the user understands the backup, device, screenshot, keyboard, clipboard and app-permission risks around putting a signing key inside a phone client.
Relays make ownership practical and imperfect
FreeFrom's FAQ explains relays in general network terms and then connects that idea to Nostr: there is no central server containing all user data, so users participate by connecting to relays, including public relays run by others. That is a useful explanation because relay behavior is the part many first-time users do not see. A social app can feel centralized if the screen is smooth, but the feed is built from events requested from relay servers.
The upside is portability. A post, profile, follow list or channel event can be signed by the user's key and read by other Nostr clients if those clients can find the event on relays they query. This is why FreeFrom's store text can say that friends and followers are accessible from other Nostr products. The relationship graph is not supposed to live only inside FreeFrom's database. It can move with the key across clients that understand the same event types.
The limits are just as real. Relays differ in retention, filtering, rate limits, moderation, search behavior and availability. A deletion request may not be honored everywhere. A private group may depend on app conventions and invitation flows that other clients do not present the same way. A media URL can disappear even when the signed event remains. FreeFrom gives the user a Nostr client, but the durability and visibility of content still depend on relay and service choices beyond the app itself.
Posts, profiles and public channels
At the everyday level, FreeFrom is a social client. The store descriptions focus on text posts, pictures, short videos, profile pages, avatars, following accounts, public chat channels and a broader world of news, technology, food, art and other accounts to follow. The official site presents similar actions through feature language: join conversations, browse public channels, showcase yourself, post articles, photos and videos, engage by commenting and liking, create or join groups, and stay connected across platforms.
That makes FreeFrom more like a general social app than a niche Nostr utility. It is not only a signer, relay monitor, command-line tool or wallet control panel. It is meant for reading, posting, discovering people and joining topic spaces from a phone. The app-store reviews also reinforce that reading: users compare it to familiar social feeds, complain about missing share-sheet integration, ask for signer support and mention missing content-warning or image-blurring behavior. Those are ordinary social-client expectations, not developer-tool expectations.
The Nostr question is which public actions remain understandable outside FreeFrom. Basic profile metadata, text notes, reactions, replies and follows have broad client support. Public chat and group behavior can be more fragmented. Nostr has multiple event families for chat, groups, moderated communities and threaded conversation. A FreeFrom user should assume normal posts travel best, while group-like experiences may feel most complete inside the app that designed them.
Private groups are a product feature, not a magic room
FreeFrom puts unusual emphasis on private groups. The official site mentions public and private groups or channels, and the FAQ describes private groups as spaces with encrypted communication, restricted access, owner or administrator control, member removal and private discussion or collaboration. The terms add a commercial edge: private channels can involve invitations, creator settings and fees denominated in sats or points depending on how the creator configures access.
That is an interesting product idea because it pulls Nostr toward paid or semi-private communities without making the whole app a marketplace. A creator can imagine a smaller discussion space, a support group, a fan room or a collaboration channel that is not simply visible to everyone who opens a public feed. Zaps and sats make that easier to imagine because social identity and small payments already sit near each other in the app's pitch.
The caution is that a private group should never be treated as a room outside all risk. Members can screenshot, copy, forward or summarize what they see. App bugs and relay behavior can matter. Payment-gated access is not the same as contractual confidentiality. Encryption protects content only within the limits of the protocol, implementation and devices involved. FreeFrom's private groups are useful precisely because they provide a more controlled app experience, but readers should still treat them as online communities, not sealed vaults.
Encrypted DMs, disappearing history and calls
FreeFrom markets encrypted direct messages and documents several chat-adjacent features. The store listings say DMs are protected by encryption algorithms. The FAQ says private chats can use a disappearing-message setting where the user selects a burn time that automatically removes locally stored history. Another FAQ entry says FreeFrom supports voice and video calls from inside private chat by tapping the plus button and choosing a call type.
Those features make FreeFrom feel more like a modern messenger than a bare Nostr feed. They are also the area where careful language matters most. Deleting local chat history is not the same as proving every copy is gone from all devices or relays. Voice and video calls may involve transport and infrastructure outside the simple relay event model. Encrypted DMs protect message content better than public posting, but they do not erase metadata such as who is communicating, when events are sent, or which services are involved.
FreeFrom also has a specific security history around this area. In June 2024, JVN published an advisory for FreeFrom versions before 1.3.5 on Android and iOS. It listed improper cryptographic signature verification, reliance on encryption or obfuscation without integrity checking, and nonce or key-pair reuse in encryption. JVN and NVD described impacts including failure to detect invalid event signatures and possible manipulation of DM content by a man-in-the-middle attack. Current store versions are later than 1.3.5, but the advisory is still part of the reader's due diligence.
Zaps make payment social
FreeFrom's FAQ explains zaps as a way to support another user's post or profile with sats through Lightning-style payment technology. That is exactly the social money pattern Nostr made famous: the tip is not hidden in a platform wallet balance, and it is not merely a like dressed up as a coin. A zap is meant to connect a social event, a recipient identity and a payment route.
For FreeFrom, the point is not that the app becomes a full wallet. The public material does not present FreeFrom as a custody product. It presents zaps as part of the social experience, much like public channels and private groups are part of the social experience. A reader can think of FreeFrom as the place where a post, author, profile, conversation or community can ask for value, while the wallet or payment backend remains a separate concern.
That distinction protects the reader from a common confusion. Zaps are useful, but they add dependencies: a profile needs a working Lightning address or LNURL-style destination, the payer needs a wallet path, the invoice has to be generated and paid, and relevant relays or services need to carry the social proof around the zap. If a zap fails, the problem may be in the app, the wallet, the recipient's payment service, the relay path or the user's network. FreeFrom makes the action approachable; it cannot remove every moving part.
Moderation lives between app rules and protocol reality
FreeFrom's public copy leans hard into a Nostr principle: the app says it has no ability to filter all content or ban accounts in the way a centralized platform can. That statement is partly about portability. A Nostr key can keep publishing elsewhere even if one app stops showing its events. A relay can reject content, but another relay may accept it. A client can hide content, but another client can display it. There is no single company account switch that controls the whole network.
At the same time, FreeFrom does have product-level moderation surfaces. Google Play mentions spam detection. The FAQ explains a report and complaint function: users can report posts through a menu, join an official FreeFrom feedback group, send a direct message to the official account or contact the project by email. It names harassment, bullying, spam, illegal or rule-breaking content, pornography, violence, hate speech, false information and fraud as examples that can be reported.
That is the real Nostr moderation shape in miniature. The app cannot govern the whole protocol, but it can curate what its users see, what its own services accept, what gets surfaced in discovery, how reports are handled and whether its own community spaces stay usable. Readers should not expect the old platform promise of universal deletion and universal banning. They should also not assume Nostr means no moderation at all. FreeFrom sits in the practical middle.
Deletion is narrower than most users expect
FreeFrom's FAQ includes an account deletion page. It describes a flow through the menu and account settings, then says FreeFrom will immediately delete all data of the account managed by FreeFrom, that the data cannot be recovered, and that the profile and name will be automatically changed to `nobody` and unable to log in to FreeFrom. That is useful because it distinguishes app-managed data from everything Nostr relays and other clients might have seen.
A normal social app user may hear `delete account` and imagine a central database purge. Nostr does not work that cleanly. Events can be copied across relays. Other clients can cache them. Screenshots and third-party indexes can persist. Deletion events can be published, but relay compliance and client interpretation vary. FreeFrom can delete what it controls and can change how its own app treats the identity, but it cannot guarantee that the whole network forgets a public event.
This matters most for photos, short videos, private group material and emotionally sensitive posts. The safer assumption is that anything public on Nostr may outlive the app session. A reader who wants to experiment should start with low-risk content, test deletion behavior, inspect how other clients see the same account, and avoid treating FreeFrom or any Nostr client as a place where a public mistake can always be pulled back everywhere.
Store distribution tells its own story
FreeFrom is distributed like a mainstream app: iOS App Store, Google Play, a direct Android APK and app-store screenshots. That gives it reach, but it also places it under store rules. The iOS listing uses a 17+ rating and notes mild profanity or crude humor. Google Play uses a Teen rating and a Data safety panel covering possible data sharing, collection, encryption in transit and deletion requests.
The Android situation deserves a closer look. Google Play rendered an install page during research, while AppBrain recorded removal from Google Play on March 31, 2026. Readers should verify the store listing from their own device and treat any direct APK install as a higher-trust decision.
The security advisory is not a footnote
The 2024 JVN advisory is one of the most important sources for evaluating FreeFrom. It affected versions before 1.3.5 on both Android and iOS. It listed three issues: invalid signature verification, missing integrity checking around security-relevant encrypted or obfuscated inputs, and reuse of a nonce or key pair in encryption. JVN's impact language was plain enough for non-specialists: the app could fail to detect invalid event data, and DM content could be manipulated by a man-in-the-middle attack.
This does not mean every current FreeFrom install has those problems. The advisory's affected range is before 1.3.5, while public store listings researched here show version 1.6.2. It does mean FreeFrom should be treated like a real security-sensitive app, not a toy social feed. Nostr clients validate signatures, hold or use private keys, show encrypted messages, interpret relayed events and sometimes handle payment-adjacent actions. A bug in those layers can change what the user thinks they are seeing or signing.
The reader takeaway is practical. Use the newest available version. Avoid old APKs. Do not import a main Nostr private key into a client until you trust the current build. Keep wallet and signer permissions separate when possible. Treat DMs as everyday private chat, not as a secure channel for high-stakes secrets. Check whether the project has an active support or release response when security advisories appear. FreeFrom's security history is not a reason to ignore it; it is a reason to evaluate it with adult eyes.
How to test FreeFrom with care
A good first test is a fresh Nostr identity. Create or import only a low-value key, publish a basic profile, follow a few accounts, join a public channel, send a non-sensitive DM and test a small post with an image. Then open the same public key in another Nostr client and see which parts travel cleanly: profile metadata, posts, follows, replies, reactions and public channel activity. That shows the boundary between protocol portability and FreeFrom-specific experience.
A second test is privacy and deletion behavior. Try account deletion only with a disposable identity. See what FreeFrom says it deletes, then check whether public events still appear through relays or other clients. Test disappearing-message settings only with harmless messages. Check Google Play Data safety and iOS privacy disclosures on the exact device and country store where you install the app. If the app requests permissions that do not fit your intended use, deny them and see whether the feature set still works for you.
A third test is payment friction. If you want to use zaps, begin with a wallet that supports low limits and revocation. Send a tiny amount, verify the recipient, and understand whether the zap appears as expected. Do not connect a wallet with meaningful funds until you know how the approval flow works. FreeFrom is interesting because it makes social identity, messaging, groups and small payments feel close together. That same closeness is why a careful first hour is worth more than a polished marketing promise.
Sources worth opening
Useful sources start with FreeFrom's own site, app-store listings, GitBook FAQ and legal/support pages, then move to JVN/NVD advisories and the NIPs behind keys, relays, chat, zaps, moderation and event deletion.
- FreeFrom official website
- FreeFrom App Store listing
- Apple iTunes Lookup for FreeFrom
- FreeFrom Google Play listing
- FreeFrom AppBrain Android listing
- FreeFrom GitBook documentation
- FreeFrom GitBook sitemap
- What is FreeFrom
- What to note when using FreeFrom for the first time
- FreeFrom user guide
- FreeFrom latest information FAQ
- FreeFrom certification FAQ
- FreeFrom FAQ: What is Nostr
- FreeFrom FAQ: How to learn about Nostr
- FreeFrom FAQ: What is Relay
- FreeFrom FAQ: What is Zap
- FreeFrom FAQ: Private groups
- FreeFrom FAQ: Disappearing private chat
- FreeFrom FAQ: Private key and public key
- FreeFrom FAQ: Voice and video chat
- FreeFrom FAQ: Delete your account
- FreeFrom FAQ: Report
- FreeFrom Terms and Conditions
- FreeFrom Privacy Policy
- FreeFrom web debug tool
- FreeFrom NostrApps profile
- JVN advisory for FreeFrom
- NVD CVE-2024-36277
- NVD CVE-2024-36279
- NVD CVE-2024-36289
- CVE-2024-36277 record
- CVE-2024-36279 record
- CVE-2024-36289 record
- Nostr protocol GitHub
- Nostr NIPs repository
- NIP-01 basic protocol flow
- NIP-04 encrypted direct messages
- NIP-07 window.nostr browser capability
- NIP-09 event deletion request
- NIP-19 Bech32 encoded entities
- NIP-25 reactions
- NIP-28 public chat
- NIP-29 relay-based groups
- NIP-40 expiration timestamp
- NIP-44 versioned encryption
- NIP-56 reporting
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-68 picture-first feeds
