You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now K4M2A inherits the follow/following model from Bluesky. One person follows another, the other may or may not follow back. It works, but it only captures one kind of relationship and not the most meaningful one.
I want to propose we add a second relationship type: Connection: a mutual bond where both people agree to it, similar to how LinkedIn has both Connect and Follow running alongside each other.
Why "followers" is the wrong word for a community like ours
In today's social media world, follower count has become a vanity metric. People create content sometimes false, sometimes just noise, purely to increase their follower numbers. The word "follow" is now associated with blind following, clout chasing, and one-sided admiration. That is not the kind of relationship K4M2A should be built around. This needs to be thought through.
A spiritual community needs a way to say: we know each other, we are on this path together, this is a real relationship, not just I clicked a button on your profile.
How it should work
Sending a connection request:
When someone wants to connect with another person, they send a request. Before sending, they can:
Select a relationship label for example: Fellow seeker, Teacher/Student, Friends, or Other
Write a short note like LinkedIn's message when sending a connection request. Something like: "We both attended satsang at ISKON, would love to stay connected."
Accepting a connection request:
The person receiving the request can see the note. When they accept, they also have the option to write a short reply, acknowledging the connection, adding context, or just saying something warm before the connection is made.
Once connected:
Both people are connected. They can still follow each other (one-sided, for content), but the Connection is a separate mutual bond that shows on both profiles.
A concrete example of why this matters
Priya and Ramesh both attended satsang at ISKON. Using the live events feature, the app surfaces that they were both at the same event and both live in Pune. Ramesh sends Priya a connection request, selects "Met at an event", and writes: "We were both at ISKON last week, would love to stay in touch."
Priya reads it, remembers the event, and accepts. She writes back: "Yes! That evening session was something else. Great to connect."
Now, on both their profiles, this connection exists not as a follower count, but as a real relationship with context about how it started.
What needs to change technically
Bluesky's current lexicon has app.bsky.graph.follow as a one-directional record. To support Connections, we would need:
A new record type, something like app.bsky.graph.connection that represents a mutual relationship and requires acceptance from both sides
A connection request state pending, accepted, or declined
Fields for: relationship label (from a defined set), and a note/message from both the sender and the acceptor
Profile UI to show Connections separately from Followers/Following
Is app.bsky.graph.connection the right place for this in the lexicon, or should this live somewhere else?
Should the defined set of relationship labels be a fixed list or user-defined?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Right now K4M2A inherits the follow/following model from Bluesky. One person follows another, the other may or may not follow back. It works, but it only captures one kind of relationship and not the most meaningful one.
I want to propose we add a second relationship type:
Connection: a mutual bond where both people agree to it, similar to how LinkedIn has both Connect and Follow running alongside each other.
Why "followers" is the wrong word for a community like ours
In today's social media world, follower count has become a vanity metric. People create content sometimes false, sometimes just noise, purely to increase their follower numbers. The word "follow" is now associated with blind following, clout chasing, and one-sided admiration. That is not the kind of relationship K4M2A should be built around. This needs to be thought through.
A spiritual community needs a way to say: we know each other, we are on this path together, this is a real relationship, not just I clicked a button on your profile.
How it should work
Sending a connection request:
When someone wants to connect with another person, they send a request. Before sending, they can:
Accepting a connection request:
The person receiving the request can see the note. When they accept, they also have the option to write a short reply, acknowledging the connection, adding context, or just saying something warm before the connection is made.
Once connected:
Both people are connected. They can still follow each other (one-sided, for content), but the Connection is a separate mutual bond that shows on both profiles.
A concrete example of why this matters
Priya and Ramesh both attended satsang at ISKON. Using the live events feature, the app surfaces that they were both at the same event and both live in Pune. Ramesh sends Priya a connection request, selects "Met at an event", and writes: "We were both at ISKON last week, would love to stay in touch."
Priya reads it, remembers the event, and accepts. She writes back: "Yes! That evening session was something else. Great to connect."
Now, on both their profiles, this connection exists not as a follower count, but as a real relationship with context about how it started.
What needs to change technically
Bluesky's current lexicon has
app.bsky.graph.followas a one-directional record. To support Connections, we would need:app.bsky.graph.connectionthat represents a mutual relationship and requires acceptance from both sidesIs
app.bsky.graph.connectionthe right place for this in the lexicon, or should this live somewhere else?Should the defined set of relationship labels be a fixed list or user-defined?
All reactions