Whistlr's relationship status redesign treats one of the oldest fields on the social web as something far more delicate than a label: a piece of shared identity that belongs to two people, not one. This deeper look goes past the announcement to the design philosophy underneath—consent-first architecture, mutual confirmation, granular audience controls, milestones, and the privacy engineering that makes a relationship status feel honest instead of performative.
We already shipped a short note explaining what the feature does. This is the other piece—the one about why it works the way it does. Because the interesting part of relationship status on Whistlr is not the list of options you can choose from. It is the set of decisions we made about who gets to speak for whom, what becomes visible and to whom, and how a deeply human moment is handled by software without flattening it into a database row. If you care about how modern social products should treat consent and identity, the relationship status feature is one of the clearest expressions of that thinking we have built.
"A relationship is the one profile detail that is never about a single person. The moment we accepted that, the engineering stopped being about a dropdown and started being about consent. Everything else followed from there."
— ETAPX Product Team
Why Relationship Status Was Broken on the Old Social Web
Relationship status is not a new idea. It was one of the defining profile fields of the early social era—a tiny line of text that carried an outsized amount of social weight. But the way it worked then now reads as careless. A single person could declare a connection to someone else without that other person ever agreeing to it. A status change could broadcast itself to an entire network in an instant, turning a private decision into a public event nobody asked for. And the visibility model was effectively binary: either everyone you knew could see it, or you hid it entirely and lost the benefit of sharing it at all.
Each of those flaws traces back to the same root assumption: that a relationship status is a property of one profile. It is not. A relationship is, almost by definition, a shared object. When you say you are married to someone, you are making a claim about another person's life, not just your own. The early social web modeled this asymmetrically—one author, one switch—and that asymmetry is the source of nearly every awkward, painful, or invasive moment the feature ever produced.
Whistlr's redesign begins by rejecting that assumption outright. On Whistlr, a confirmed relationship is a mutual object owned by two people. Neither person can author the truth of it alone. That single architectural decision changes everything downstream—the request flow, the database schema, the visibility rules, the notifications, even what happens when a relationship ends.
Consent-First Design as a Default, Not a Setting
The phrase "consent-first" gets used loosely. On Whistlr it has a precise meaning: no relationship appears anywhere on the platform until both people have explicitly agreed to it. There is no version of the feature where consent is an optional checkbox you can disable for convenience. It is structural. It is the only path the system offers.
Concretely, the lifecycle of a relationship looks like this. One person proposes a status toward someone else. That proposal is a request, not a fact—it does nothing to the recipient's profile and is not visible to anyone but the two people involved. The recipient can accept, decline, or simply let it sit. Only when they accept does a confirmed relationship come into existence, and only then does it surface on either profile. Until that moment, the status is private potential energy. It has no public reality.
This matters because it inverts the burden. On legacy platforms, the burden was on the unwilling participant to discover they had been tagged and then undo it—often after friends, family, or strangers had already seen it. On Whistlr, nothing exists to undo. The default state is "no relationship is shown," and the only way out of that default is a deliberate, affirmative action from the person whose identity is being described. Consent is not the thing you opt into. It is the thing the entire feature is built on.
"We did not want a 'remove tag' button. A remove-tag button is an apology for a design that should never have published the thing in the first place. The right answer is that nothing publishes until both people say yes."
— ETAPX Engineering
The Follower Gate: Earning the Right to Ask
There is a subtle precondition that sits even before the request, and it reveals a lot about the platform's values. You cannot send a relationship request to just anyone. The person you are proposing a status with must already follow you. If they do not follow you, the request is blocked before it is ever created, with a friendly explanation that they need to follow you first.
This is a deliberate piece of anti-harassment design. Relationship requests are intimate by nature, and an open inbox for them would be an obvious vector for unwanted attention, impersonation games, and low-grade harassment. By requiring an existing follow relationship, Whistlr ensures that a relationship request can only travel along a connection the recipient has already chosen to form. The follow is the recipient's first, lightweight act of consent—a signal that they have at least invited this person into their world. Only then does the platform permit the much weightier ask of a relationship status.
It also keeps the feature honest. Relationship status on Whistlr is meant to reflect real connections between people who actually know each other, not aspirational claims or stunts directed at strangers. The follower gate quietly enforces that intent without a single moderation report being filed.
Mutual Confirmation: How a Status Becomes Real
Mutual confirmation is the heart of the system, so it is worth walking through exactly how it works, step by step, because the details are where the care lives.
- The request. You open a profile of someone who follows you and choose to add a relationship. You pick a category—personal or professional—and a status, optionally attach a start date, a short message, and an audience setting. Nothing is published. A private request is created and the recipient is notified.
- The notification. The recipient receives a warm, human notification framed around the specific status. The system intentionally varies the language: a proposal of "Engaged" reads differently from "In a relationship," which reads differently from a business partnership invite. The tone is matched to the moment rather than rendered as a generic system alert.
- The decision. The recipient sees the full request—who, what status, any message, and for professional requests the partnership details—and chooses to accept or decline. There is no time pressure inside the app; the request simply waits.
- Confirmation. On acceptance, and only then, the platform creates the confirmed relationship and it becomes visible according to the chosen audience. The original requester is notified that their request was accepted. The status is now real, mutual, and shared.
- Decline, quietly. If the recipient declines, the requester is not subjected to a public rejection. The request closes. The platform does not stage drama around a "no."
Under the hood, acceptance does something most users never see but that captures the philosophy precisely: it writes two relationship records, not one. When a request is confirmed, the system creates a record from the sender's perspective and a mirror record from the recipient's perspective, both flagged as confirmed and stamped with the same confirmation time. The relationship is genuinely bidirectional in the data, not a single row that one profile happens to point at. Each person owns their side of the shared truth. This is why the status appears symmetrically on both profiles, and why ending it has to be handled symmetrically too.
Expiry: Requests Are Not Forever
A pending relationship request is not an open-ended obligation hanging over someone's head. Each request carries an expiry—roughly a month—after which it lapses on its own. This small detail does real emotional work. It means an awkward or premature ask does not become a permanent fixture in someone's inbox, and it means a request someone is unsure about will quietly resolve itself rather than demanding a confrontation. Silence becomes a safe, valid response. Not every "no" should require the person to say it out loud.
One Relationship at a Time: An Honesty Constraint
One of the more opinionated decisions in the system is that a person can hold only one confirmed, active personal relationship at a time. When a request is sent and again when it is accepted, the platform checks both people for an existing active relationship and refuses to create a conflicting one, returning a clear message rather than silently overwriting anything.
We debated this. The constraint trades some flexibility for integrity. But it reflects what a relationship status is for on a profile: a single, current, true statement about a primary connection. Allowing an unlimited stack of simultaneous confirmed relationships would have turned a meaningful identity signal into noise, and it would have created obvious avenues for confusion and abuse. The single-active-relationship rule keeps the field meaningful. If your situation changes, you end the existing relationship first—and because that ending is itself handled with care, the transition is clean rather than messy.
Importantly, this constraint applies to the personal category. The professional side of the feature—business partnerships—is modeled to allow the richer, many-to-many reality of professional life, where someone can legitimately hold several concurrent partnerships. The platform draws a deliberate line between the two, which brings us to the identity layer.
The Identity Layer: Personal and Professional in One System
Relationship status on Whistlr is not only about romance. The same consent-first machinery powers a second category: business partnerships. This was an intentional expansion of the concept, and it reframes "relationship status" as a general-purpose identity layer for declaring confirmed connections between people—whatever kind they are.
The personal category covers the statuses you would expect, and a few that older platforms forgot or quietly omitted: In a relationship, Engaged, Married, In an open relationship, In a civil union, In a domestic partnership, and the famously honest "It's complicated." The display layer gives each status its own visual treatment—an engagement carries a different icon and color from a marriage, which differs again from "it's complicated"—so a glance at a profile communicates not just that there is a relationship but something of its texture. Statuses like Widowed, Divorced, and Separated exist in the underlying model as well, acknowledging that relationship history is part of a full identity and not only its current happy state.
The professional category is genuinely deep. A business partnership request can specify a partnership type—Co-founders, Joint Venture Partners, Strategic Partners, Angel Investor and Founder, VC and Founder, and many more—along with an industry, your role, the partnership status, a company or partnership name, a website, and a short description. The result is that a profile can show, with both parties' confirmation, that two people are co-founders of a named company in a named industry, with defined roles, since a particular date. For the creator economy and for professional networking, this is a structured, verifiable claim of the kind that loose bio text could never reliably make.
- Personal relationships express a single, current, primary connection with rich emotional context and tight audience control.
- Business partnerships express professional connections with structured metadata—type, industry, role, company—and allow the many-to-many shape that real professional life takes.
- Shared machinery means both run on the same consent-first request-and-confirm flow, so the trust guarantees are identical whether the connection is a marriage or a merger.
Treating both under one identity layer is more than engineering economy. It signals a worldview: the connections that define us are not only romantic, and a profile should be able to tell the truth about who you build with as readily as who you love—always with the other person's agreement.
The Old Way Versus the Whistlr Way
It helps to put the two models side by side, because the differences are not cosmetic—they are structural, and each one resolves a specific failure of the era that came before.
Authorship: one voice versus two
The old model let a single person author a relationship. You could set yourself as "in a relationship with" someone, and the platform would dutifully publish it, attaching that claim to another human being who never agreed to it. Whistlr requires two voices. A relationship is co-authored or it does not exist. The asymmetry that produced so much old-internet awkwardness—people discovering they had been "set" as someone's partner—is simply not expressible in the system.
The breakup: an event versus an absence
The old model treated a status change as content. Flipping to "single" generated a feed-worthy event that invited attention precisely when a person wanted none. Whistlr treats the end of a relationship as the quiet removal of a fact, not the publication of a new one. The difference is the difference between a spotlight and a dimmer switch.
Visibility: a switch versus a spectrum
The old model offered, in practice, two states: visible to your whole network or hidden. Whistlr offers four calibrated audiences plus a master override, because the truth of how people share is that "everyone" and "no one" are rarely the right answer. Most of the time the right answer is "these particular people," and the platform now has a vocabulary for that.
Requests: an open door versus an earned invitation
The old model rarely gated who could attach themselves to you. Whistlr gates it twice—once through the follower requirement and again through your own per-account request settings—so the most intimate ask on the platform can only reach you along a path you have already approved.
None of these contrasts is about adding features for their own sake. Each one is a direct repair of a specific way the previous generation of social software mishandled something personal. The redesign is, in a real sense, a list of old apologies turned into new defaults.
Granular Audience Controls: Visibility as a Spectrum
The third pillar, after consent and mutual confirmation, is control over who actually sees a confirmed relationship. The old binary—public or hidden—is replaced with a spectrum of audiences that map to how people genuinely think about sharing personal information.
- Public: anyone can see the relationship, including people who do not follow you. The most open setting, appropriate for a status you are happy to celebrate widely.
- Followers: only the people who follow you can see it. Your relationship is visible to the audience you have chosen to build, and invisible to passing strangers.
- Circle: only mutual followers—people you follow who also follow you back—can see it. This is the close-connections tier, for sharing with the people you actually know rather than your full follower count.
- Private: only you can see it. The relationship is confirmed and real in the system, but it stays off your public profile entirely. You get the record without the broadcast.
The Circle tier deserves special attention because it embodies a uniquely modern intuition. Many people are comfortable telling their real friends about their relationship but uneasy about announcing it to thousands of followers, coworkers, and acquaintances. Circle gives that middle ground a first-class home. It maps to the social reality that "the people who follow me" and "the people I actually trust with personal news" are two very different groups.
Crucially, visibility is chosen per relationship at the moment of the request, and there is a separate profile-level switch—Show relationship on profile—that acts as a master control. Even a confirmed, public relationship can be kept off your profile entirely with that toggle. Layered controls like this mean privacy is never a single point of failure; you can be precise at the relationship level and still have a global override you can flip at any time.
Controlling Who Can Even Ask
Audience control is not only about who can see; it is also about who can reach you. The relationship settings let you decide who is allowed to send you requests at all: everyone, followers only, or your circle of mutual follows. You can also turn off incoming relationship requests entirely. When that switch is off, the platform refuses any incoming request at the source, returning a clear message that the user does not accept relationship requests. This is consent applied at the front door, before a request is ever created—a quieter, calmer inbox by design.
Milestones: A Relationship Has a Beginning
A status without time is a flat fact. A status with a date is a story. Whistlr lets either party attach a start date to a relationship, and once confirmed, profiles display the connection alongside a "Since" date—for example, married to a partner since a particular month and year, or co-founders of a company since a given date.
This milestone layer turns the relationship field from a static label into a small, living anniversary. It rewards longevity and gives the connection a sense of history that a bare status never could. For business partnerships, the start date doubles as useful professional context—how long a co-founding relationship has lasted is meaningful signal. For personal relationships, "Since" is quietly sentimental in exactly the way the feature intends. The date is optional, never required, and it is shared under the same visibility rules as the rest of the relationship, so a milestone is celebrated only with the audience you have chosen.
The Announcement, Done Tastefully
When two people confirm a personal relationship and have chosen a public audience, Whistlr can mark the moment with a gentle announcement post from the initiator's account—a single, warm line celebrating the new status, complete with a fitting flourish for the occasion. An engagement reads differently from a marriage, which reads differently from a new relationship.
The design restraint here is the point. The announcement only happens for confirmed, public, personal relationships—never for private or limited-audience statuses, and the platform treats the post as non-essential, so the relationship itself is created whether or not the celebratory post succeeds. There is no automatic broadcast for a relationship you chose to keep within your circle or to yourself. The system celebrates only what you have explicitly chosen to celebrate publicly, and it does so once, cleanly, rather than spamming every visibility change into the feed. Joy is opt-in.
Ending a Relationship Without the Old Cruelty
No part of the old relationship-status experience aged worse than the breakup. A status flipping from "In a relationship" to "Single" once functioned as an involuntary public announcement, complete with the unwanted attention that followed. Whistlr was designed to never do that.
Ending a relationship on Whistlr is symmetrical and quiet. Either person can end it. When they do, the platform closes both sides of the bidirectional record at the same time, so the status disappears from both profiles together rather than leaving a confusing half-ended state where one person still appears attached to someone who has moved on. The system also cleans up any lingering pending requests between the two people, so the slate is genuinely clear.
What it does not do is just as important. It does not generate a "broke up" announcement. It does not push the change into anyone's feed. It does not stage the ending as an event. The relationship simply stops being shown. For most people, that silence is the most humane feature in the entire system—the absence of a spotlight at the exact moment they would least want one.
"The kindest thing software can do during a breakup is nothing. No banner, no broadcast, no badge of newfound singleness. Just a quiet, mutual close. We engineered for that absence on purpose."
— ETAPX Product Team
Privacy Engineering Beneath the Surface
The feeling of safety this feature provides is not an accident of good copywriting; it is a property of how the system is built. A few of the engineering decisions are worth surfacing because they show that the privacy promises are enforced in code rather than merely stated in policy.
- Server-enforced rules. The critical actions—sending, accepting, declining, and ending—run through trusted server-side functions rather than direct client writes. The follower-gate check, the receiver's "do you accept requests" preference, the one-active-relationship constraint, the duplicate-request check, and the receiver-only authority to accept are all verified on the server. A modified client cannot talk its way past them.
- Authority checks on every action. Only the receiver of a request can accept or decline it; only a participant in a relationship can end it. The server confirms identity against the record before making any change, so no one can act on a relationship they are not part of.
- Atomic, reversible writes. Because confirmation creates two mirrored records plus a status update, the system rolls back partial work if any step fails. You never end up with a half-created relationship that exists on one profile but not the other.
- Realtime that respects scope. Profiles and request lists subscribe to live updates scoped narrowly to the relevant user, so an accepted request reflects instantly for the right people without leaking change events to anyone else.
- Visibility enforced at read time. A relationship marked private or limited to a circle is not simply hidden by the interface; the data is fetched with the visibility and profile-display settings in mind, so hiding a status actually withholds it rather than relying on the client to look away.
This is what we mean when we say consent is structural. The guarantees a user feels—"nobody can claim me without my yes," "nobody outside my circle sees this," "I can end it without a scene"—are each backed by a specific check in a specific place in the system. The privacy is load-bearing, not decorative.
What This Looks Like in Real Life
Abstractions are easier to trust when you can picture them. Here are a few situations the design was built to handle gracefully.
The new couple who want to tell only their friends
Two people who recently started dating want to acknowledge it, but neither is ready to announce it to thousands of followers, including coworkers. One sends a request with the audience set to Circle. The other accepts. Now the relationship shows only to people they both actually know. No public post is generated, because the audience is not public. They get the warmth of acknowledgment without the exposure of a broadcast.
The co-founders formalizing a partnership
Two people launching a company want their profiles to reflect it. One sends a professional request specifying co-founders, the industry, both roles, the company name, and a start date. The other confirms. Both profiles now display a structured, mutually verified partnership—useful for investors, collaborators, and anyone vetting the team—because both parties stood behind the claim.
The person who wants the record but not the spotlight
Someone is in a committed relationship but is intensely private online. They confirm the relationship with visibility set to Private, or they leave the master "show on profile" switch off. The relationship is real in the system, the start date is recorded, and absolutely nothing appears publicly. The platform respects the choice to keep something true and unshared.
The quiet ending
A relationship ends. One person opens their settings and ends it. Both profiles update together; pending requests clear; no announcement fires; no feed item appears. The next time anyone visits either profile, the status is simply no longer there. The hardest moment is handled with the least possible noise.
How Relationship Status Fits the Wider Whistlr Ecosystem
Relationship status does not live in isolation. It is one expression of a philosophy that runs through the whole platform—the same friend-first, consent-aware instinct that shapes how Whistlr handles feeds, messaging, communities, stories, Minis, and live streaming. The follower gate that protects relationship requests is the same notion of earned access that governs much of the social graph. The circle-of-mutuals audience tier echoes the small-circles thinking behind how Whistlr lets people share with the right group rather than the whole crowd.
The professional partnership layer connects directly to Whistlr's broader creator and business tooling, giving the connections people form for work a verifiable home on the profile rather than relegating them to unverifiable bio text. And the structured, mutually confirmed nature of relationship data means it can participate cleanly in the rest of the experience—powering richer profiles, more meaningful discovery of how people are connected, and a social graph that reflects reality because both sides of every link agreed to it. A platform that wants honest connection has to make its connection objects honest, and relationship status is where that principle is most visible.
Why the Professional Layer Matters for Creators and Builders
It would be easy to read the business-partnership half of this feature as a footnote to the romantic half. It is not. For the people who build careers and companies on a social platform, a mutually confirmed, structured record of professional relationships solves a problem that has nagged the creator economy for years: the gap between what someone claims about their collaborations and what anyone can actually verify.
Bio text is cheap. Anyone can write "co-founder" or "advised by" in a profile description, and there is no mechanism behind the words. A confirmed partnership on Whistlr is different in kind. Because it requires the other party to accept, a displayed co-founder relationship carries the weight of mutual agreement. Because it is structured—type, industry, role, company, start date—it can be read consistently rather than parsed out of free-form prose. And because it is owned bidirectionally, it appears on both profiles, so the claim is corroborated from both sides rather than asserted from one.
Consider what that enables. An investor vetting a founding team can see, at a glance, that the people listed as co-founders have each confirmed the relationship and the roles they hold. A brand evaluating a creator's stated partnerships sees connections both parties stood behind. A collaborator deciding whether to join a project can read an honest map of who is already involved and in what capacity. The professional layer turns a profile from a marketing surface into something closer to a verifiable record—without requiring contracts, paperwork, or any third-party attestation, just the same simple mutual yes that powers the rest of the feature.
And because the professional category deliberately allows multiple concurrent partnerships, it fits the actual texture of a working life. People co-found one company while advising another and partnering with a third. The personal category enforces a single primary relationship because that reflects the truth of personal life; the professional category permits many because that reflects the truth of professional life. The same machinery, tuned to two different realities.
Edge Cases the Design Anticipates
A feature this personal lives or dies on its edge cases—the awkward, in-between moments where a careless system would create pain. Several of these were designed for explicitly.
- The duplicate request. If a request already sits pending between two people, the system will not let a second one be created, in either direction. You cannot pile requests on someone, and two people cannot accidentally create competing proposals to each other.
- The expired request. A request that has lapsed cannot be accepted. If you try to confirm something that timed out, the system declines and tells you it expired, rather than quietly resurrecting a stale proposal.
- The already-taken partner. If, between sending a request and its acceptance, either person enters a confirmed relationship with someone else, the acceptance is refused with a clear message. The one-relationship rule is enforced at confirmation time, not just at request time, so a race between two pending requests resolves cleanly instead of producing a contradiction.
- The half-written relationship. Because confirmation writes two mirrored records and updates the request, a failure partway through rolls the whole operation back. There is no state where you are shown as attached but your partner is not, or vice versa.
- The request to someone who closed their inbox. If the recipient has turned off relationship requests, the request is refused at the source with a plain explanation, so a sender is not left wondering why a request seems to have vanished.
- The request to yourself. Trivial but worth handling: the system rejects an attempt to send a relationship request to your own account rather than letting it create nonsense data.
None of these are glamorous. Collectively, they are the difference between a feature that feels trustworthy and one that occasionally betrays you at the worst possible moment. The polish lives in the cases most users will never deliberately trigger.
What This Signals About Modern Social Design
Step back and the relationship feature reads as a small thesis about where social software should go. For years the industry optimized profiles for broadcast: more fields, more visibility, more automatic sharing, all defaulting toward maximum exposure because exposure drove engagement. The cost of that approach—on privacy, on consent, on the simple dignity of controlling your own story—was paid by users, quietly, for a long time.
Whistlr's relationship status redesign argues for a different default. It says that the most personal corners of a profile should be opt-in, mutual, and reversible. It says that the platform's job is to give people precise control and then get out of the way—celebrating only what they choose to celebrate, showing only what they choose to show, and saying nothing at the moments when silence is the kindest response. It treats a relationship as a shared object owned by two consenting people rather than a field one person can flip. That is a more difficult thing to build than a dropdown, and the difficulty is the point.
"We think the next era of social products will be judged less by how much they let you broadcast and more by how carefully they protect the things that are not yours alone to share. Relationship status was our chance to prove we mean that."
— ETAPX Product Team
Frequently Asked Questions
Can someone list a relationship with me without my permission?
No. This is the central guarantee of the feature. A relationship only becomes real and visible after you explicitly accept the request. Until you accept, the proposal is a private request that does nothing to your profile and is seen by no one but the two of you. There is no way for another person to publish a relationship status that involves you without your direct, affirmative confirmation.
Why can I only have one active personal relationship at a time?
Because a relationship status is meant to be a single, current, true statement about a primary connection. The platform checks for an existing active relationship when a request is sent and again when it is accepted, and it will not create a conflicting one. If your situation changes, you end the current relationship first—an action handled quietly and symmetrically—and then you are free to confirm a new one. Business partnerships, by contrast, are designed to allow multiple concurrent connections.
Who can see my relationship status?
Exactly the audience you choose. Each relationship is set to one of four visibility levels: Public (everyone), Followers (your followers only), Circle (mutual follows only), or Private (only you). On top of that, a master "show relationship on profile" switch can hide your status entirely regardless of its visibility setting. You decide, at a fine grain, who is included.
What happens to my profile when a relationship ends?
The status simply disappears from both profiles at the same time, because the platform closes both sides of the relationship together. No announcement is created, nothing is pushed into anyone's feed, and the change is not staged as an event. Any pending requests between the two of you are also cleared. The ending is deliberately quiet.
Why do I have to be followed by someone before I can send them a relationship request?
It is an anti-harassment safeguard. Requiring an existing follow means a relationship request can only travel along a connection the recipient already chose to form, which prevents strangers from sending intimate or unwanted requests. It also keeps the feature anchored to real connections between people who actually know each other. If the person does not follow you, the request is blocked before it is created.
Does Whistlr announce my relationship automatically?
Only if you choose to share it publicly. A gentle, one-time celebratory post can be created when a personal relationship is confirmed with a public audience. If you set the visibility to Followers, Circle, or Private, no public announcement is generated. The platform celebrates only what you have explicitly opted to celebrate, and it never announces a breakup.
How is the professional partnership feature different from a personal relationship?
It runs on the same consent-first, request-and-confirm machinery, so the trust guarantees are identical, but it captures different information and follows different rules. A business partnership can include a partnership type, industry, your role, a company or partnership name, a website, and a description, producing a structured, mutually verified professional claim. Unlike personal relationships, you can hold multiple active partnerships at once, reflecting the real shape of professional life.
What if I receive a request I am not sure about?
You can simply do nothing. Requests are not visible to anyone else, there is no in-app pressure to respond, and every request carries an expiry of roughly a month, after which it lapses on its own. Silence is a valid and private answer. If you prefer, you can decline, which closes the request without any public rejection of the sender, or you can adjust your settings to limit or turn off who can send you requests in the first place.
Where Relationship Status Goes From Here
The version of relationship status we have built is a foundation, not a finish line. The same consent-first, mutually-owned model that powers personal and professional connections today is general enough to extend toward the other meaningful relationships people want to represent honestly—and every extension will inherit the same non-negotiable rules: nothing is published without both parties' agreement, audiences stay precise and user-controlled, and endings stay quiet. As Whistlr's profiles, discovery, and creator tools continue to deepen, structured and consented relationship data gives the whole platform a more truthful map of how people are actually connected.
What will not change is the philosophy underneath it. We are convinced that the parts of a profile that describe other people deserve the highest bar a social platform can set for consent and control, and that meeting that bar is not a constraint on a good product but the substance of one. Relationship status, reimagined, is our clearest statement of how we think identity should work on a social network built for real connection: shared, consented, and yours to control. That is the standard we intend to hold ourselves to as the feature, and the platform around it, keep growing.
