DEV Community: real name hidden

I replaced the like button with a weighted slider. Here's the architecture behind it.

real name hidden — Tue, 17 Mar 2026 05:24:35 +0000

Every social platform has a reaction system. Facebook has six emoji reactions. Twitter has a heart. Instagram has a heart. Reddit has upvote/downvote. They all share the same fundamental design: a binary or near-binary signal that tells the algorithm "more of this" or "less of this."
I built a social platform called LINKWAVEZ where the reaction system works differently. Instead of a like button, users respond with a Resonance Slider — a continuous input that weights their reaction between two values: Aura (emotional impact) and Wisdom (intellectual impact).
This post explains the technical architecture behind that system and the dual scoring engine it feeds into.
The Resonance Slider
When a user sees a post (we call them Poses), they can react by dragging a slider between two poles. Full left is pure Aura — the post moved them emotionally. Full right is pure Wisdom — the post made them think. Most reactions land somewhere in the middle.
The slider outputs a value between 0.0 and 1.0, where 0.0 is pure Aura and 1.0 is pure Wisdom. The database stores both the raw slider value and the computed weights:
sqlCREATE TABLE pose_reactions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
pose_id UUID NOT NULL REFERENCES poses(id) ON DELETE CASCADE,
user_id UUID NOT NULL REFERENCES auth.users(id),
slider_value FLOAT NOT NULL CHECK (slider_value >= 0 AND slider_value <= 1),
aura_weight FLOAT GENERATED ALWAYS AS (1.0 - slider_value) STORED,
wisdom_weight FLOAT GENERATED ALWAYS AS (slider_value) STORED,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
UNIQUE(pose_id, user_id)
);
The aura_weight and wisdom_weight columns are generated columns — computed automatically from the slider value. This avoids any client-server mismatch in weight calculation.
How reactions flow into the scoring system
LINKWAVEZ has a dual scoring system: every user has an Aura score and a Wisdom score. These are aggregate reputation metrics that reflect how you impact the community.
When someone reacts to your post with the Resonance Slider, the reaction flows through a scoring pipeline:
Reaction event
→ Calculate base points (3 points per reaction)
→ Split by slider weights
→ Apply area multiplier (Feed area = 1.0x)
→ Check daily caps
→ Credit to post creator's Aura and Wisdom
→ Update area scores
→ Recalculate overall scores
Here's the Node.js handler:
javascriptasync function processReaction(poseId, reactorId, sliderValue) {
const basePoints = 3;
const auraPoints = basePoints * (1.0 - sliderValue);
const wisdomPoints = basePoints * sliderValue;

// Check daily caps before crediting
const todayScores = await getTodayScores(creatorId, 'feed');

const cappedAura = Math.min(
auraPoints,
DAILY_AURA_CAP_FEED - todayScores.aura
);
const cappedWisdom = Math.min(
wisdomPoints,
DAILY_WISDOM_CAP_FEED - todayScores.wisdom
);

if (cappedAura > 0 || cappedWisdom > 0) {
await creditScores(creatorId, 'feed', cappedAura, cappedWisdom);
}
}
The daily cap system
This is where the design gets interesting from an anti-gaming perspective.
LINKWAVEZ has 9 scoring areas: Feed, Moments, Groups, Marketplace, Events, Social, Mentorship, Partnership, and Echo. Each area has separate Aura and Wisdom sub-scores. The overall score is a weighted average across all areas.
Every area has a daily cap. The total maximum across all areas is 275 Aura points per day. No matter how viral your content goes, you can't earn more than the cap in a single day.
javascriptconst DAILY_CAPS = {
feed: { aura: 70, wisdom: 50 },
moments: { aura: 30, wisdom: 30 },
groups: { aura: 40, wisdom: 35 },
marketplace: { aura: 25, wisdom: 15 },
events: { aura: 25, wisdom: 15 },
social: { aura: 35, wisdom: 25 },
mentorship: { aura: 20, wisdom: 30 },
partnership: { aura: 15, wisdom: 20 },
echo: { aura: 15, wisdom: 25 },
};
// Total max aura/day: 275
Why does this matter technically? Because the cap check needs to be atomic. If 50 people react to your post simultaneously, you can't just credit all of them and check the cap afterward — you'd overshoot. The solution is a PostgreSQL function with row-level locking:
sqlCREATE OR REPLACE FUNCTION credit_score_capped(
p_user_id UUID,
p_area TEXT,
p_aura FLOAT,
p_wisdom FLOAT
) RETURNS TABLE(credited_aura FLOAT, credited_wisdom FLOAT) AS $$
DECLARE
current_daily RECORD;
cap RECORD;
actual_aura FLOAT;
actual_wisdom FLOAT;
BEGIN
-- Lock the user's daily score row
SELECT * INTO current_daily
FROM daily_scores
WHERE user_id = p_user_id
AND area = p_area
AND score_date = CURRENT_DATE
FOR UPDATE;

-- Calculate what we can actually credit
actual_aura := LEAST(p_aura, cap.aura - COALESCE(current_daily.aura, 0));
actual_wisdom := LEAST(p_wisdom, cap.wisdom - COALESCE(current_daily.wisdom, 0));

-- Credit
INSERT INTO daily_scores (user_id, area, score_date, aura, wisdom)
VALUES (p_user_id, p_area, CURRENT_DATE, actual_aura, actual_wisdom)
ON CONFLICT (user_id, area, score_date)
DO UPDATE SET
aura = daily_scores.aura + actual_aura,
wisdom = daily_scores.wisdom + actual_wisdom;

RETURN QUERY SELECT actual_aura, actual_wisdom;
END;
$$ LANGUAGE plpgsql;
The FOR UPDATE lock ensures that concurrent reactions don't blow past the cap. This is critical for any scoring system that has limits.
The Emotional Temperature system
Every post in LINKWAVEZ carries an Emotional Temperature — a mood tag set by the creator: Calm, Warm, Playful, Intense, or Charged.
This feeds into two systems:

Feed filtering. Users can filter their feed by energy level using the Vibe Spectrum Filter. The filter maps temperatures to a spectrum from Deep to Energized: Deep ← Calm ← Warm ← Playful → Intense → Charged → Energized The query is straightforward — it's just a WHERE clause on the temperature column. But the UX impact is significant. A user having a rough morning can filter to Calm and see only gentle, reflective content. The feed respects their emotional state.
Auto Emoji Vibe. After a post receives 3 or more replies, the system analyzes the reply sentiment and assigns an emoji vibe to the post card. This is done with a simple keyword frequency analysis across all replies: javascriptfunction detectVibe(replies) { const signals = { hilarious: 0, fire: 0, heartfelt: 0, mindblown: 0 };

for (const reply of replies) {
const text = reply.content.toLowerCase();
if (/haha|lol|😂|🤣|funny|hilarious/.test(text)) signals.hilarious++;
if (/🔥|fire|amazing|incredible|insane/.test(text)) signals.fire++;
if (/❤️|💜|love|beautiful|heart|crying/.test(text)) signals.heartfelt++;
if (/🤯|mind|blown|wow|whoa|never thought/.test(text)) signals.mindblown++;
}

const dominant = Object.entries(signals)
.sort((a, b) => b[1] - a[1])[0];

if (dominant[1] >= 3) return dominant[0];
return null;
}
When a vibe is detected, the post card gets a subtle color tint and emoji badge. It's a small touch but it makes the feed feel alive and responsive to the community's actual reactions.
The feed algorithm: 70/20/10
Most social feeds show you more of what you already like. LINKWAVEZ deliberately breaks that pattern.
The feed composition is:

70% content aligned with your interests and values
20% content from different perspectives (the Echo Chamber Breaker)
10% pure discovery from random users

The implementation uses a weighted random sampling approach. For each feed load, we pull three separate query results and interleave them:
javascriptasync function buildFeed(userId, page, perPage) {
const alignedCount = Math.round(perPage * 0.7);
const differentCount = Math.round(perPage * 0.2);
const discoveryCount = perPage - alignedCount - differentCount;

const [aligned, different, discovery] = await Promise.all([
getAlignedPosts(userId, alignedCount),
getDifferentPerspectives(userId, differentCount),
getRandomDiscovery(userId, discoveryCount),
]);

// Interleave: don't cluster all "different" posts together
return interleave(aligned, different, discovery);
}
The getDifferentPerspectives query is the interesting one. It finds users whose reaction patterns on shared content differ significantly from the current user. If you consistently slide toward Wisdom on political posts and another user consistently slides toward Aura on the same posts, you have different perspectives worth exposing to each other.
Users can adjust the 70/20/10 ratio with sliders in settings. Some people want more challenge. Some want more comfort. But the default is intentionally set to gently expand your bubble.
Group auto-evolution
One more system worth discussing: groups in LINKWAVEZ evolve automatically based on community activity.
Every group starts as a Ripple (2-12 members). When it hits 13 active members and meets engagement thresholds, it auto-evolves into a Current (up to 100 members). Hit 100 with sustained activity, and it becomes a Tide (unlimited).
Each evolution unlocks new features: more post types, admin tools, analytics, pin slots. The evolution check runs as a scheduled job:
javascript// Runs daily at midnight
async function checkGroupEvolutions() {
const ripples = await getGroupsByStage('ripple');

for (const group of ripples) {
const activeMembers = await countActiveMembers(group.id, 7); // active in last 7 days
const weeklyPosts = await countRecentPosts(group.id, 7);

if (activeMembers >= 13 && weeklyPosts >= 20) {
  await evolveGroup(group.id, 'current');
  await notifyMembers(group.id, 'Your Ripple has grown into a Current!');
}

}
}
The auto-evolution removes the burden from group admins to manually "upgrade" their community. The system recognizes organic growth and responds to it.
The stack
For anyone building something similar:

Flutter for cross-platform mobile (single codebase for Android and iOS)
Node.js for the backend API (Express, handles scoring logic and scheduled jobs)
Supabase for auth, PostgreSQL database, Realtime subscriptions, and file storage
Row Level Security policies handle all data access control at the database level

Total monthly infrastructure cost for the current scale: under $100. Supabase's Pro plan handles a surprising amount of traffic before you need to think about scaling.
What's live
LINKWAVEZ has over 150 features across social feed, groups, marketplace, events, mentorship, and wellness modules. It's live on Google Play as "LINKWAVEZ: Calm Social."
If you're interested in the technical side of building social platforms — especially the scoring, feed algorithms, or real-time architecture — happy to go deeper in the comments.
Download: [https://play.google.com/store/apps/details?id=com.linkwavez.app&pcampaignid=web_share
]
Website: linkwavez.com

I built a pre-send tone analyzer into a chat app using Flutter and Supabase

real name hidden — Tue, 17 Mar 2026 05:22:01 +0000

Most messaging apps optimize for one thing: delivery speed.
Message typed. Message sent. Message delivered. Done. The entire pipeline is built around getting bytes from point A to point B as fast as possible.
Nobody stops to ask: should this message be sent at all?
I've been building a messaging app called Kindly for the past couple of years. It's a Flutter app backed by Supabase, and the feature that gets the most reaction from other developers isn't the real-time chat system or the media handling. It's a tiny feature I almost didn't build: the Tone Check.
What the Tone Check actually does
Before a message leaves your device, Kindly runs a lightweight keyword analysis on the text. If the message contains patterns that commonly read as harsh, dismissive, or aggressive in text form, a small non-blocking banner appears:

"This might sound a bit sharp. Send anyway?"

The user can dismiss it instantly and send. There's no gate. No censorship. Just a one-second pause that lets the sender re-read their own words with fresh eyes.
Here's why this matters technically: text-based communication strips away every non-verbal signal that humans rely on. No facial expressions. No vocal tone. No body language. Studies show that the receiver interprets the emotional tone of a text message differently from the sender roughly 50% of the time. Half of all text messages land with a different emotional weight than intended.
The Tone Check doesn't use a heavy ML model. It's a local keyword and pattern matcher that runs entirely on-device. No API calls. No latency. No privacy concerns from sending message content to a server.
The implementation approach
The analyzer runs through a few layers:
Layer 1: Direct keyword flags. Words and phrases that almost always read as aggressive in text: "whatever," "fine," "I don't care," "do what you want." These aren't inherently rude in speech, but in text they carry weight.
Layer 2: Punctuation patterns. ALL CAPS detection. Excessive exclamation marks. Periods at the end of short messages (research shows a single period after "Ok." reads as passive-aggressive to younger users).
Layer 3: Absence of softeners. Messages that are commands without courtesy words. "Send me the file" vs "Could you send me the file?" The analyzer flags when a message is imperative without softening language.
The entire thing runs in under 5 milliseconds on a mid-range Android device. It's synchronous — the send button checks the result before dispatching. If the check passes, the message goes out with zero perceived delay.
dart// Simplified concept — actual implementation has more nuance
class ToneAnalyzer {
static ToneResult analyze(String message) {
final lower = message.toLowerCase().trim();
double sharpness = 0.0;

// Layer 1: keyword detection
for (final pattern in _harshPatterns) {
  if (lower.contains(pattern.text)) {
    sharpness += pattern.weight;
  }
}

// Layer 2: punctuation
if (message == message.toUpperCase() && message.length > 3) {
  sharpness += 0.4; // ALL CAPS
}

// Layer 3: imperative without softener
if (_isImperative(lower) && !_hasSoftener(lower)) {
  sharpness += 0.2;
}

return ToneResult(
  shouldWarn: sharpness >= 0.5,
  sharpness: sharpness,
);

}
}
The threshold is configurable per chat. Some people want it sensitive. Some want it only for obvious aggression. The setting persists locally — no server roundtrip needed.
The Breathing Space: synced cooldowns over Supabase Realtime
The second feature I want to talk about is Breathing Space. This one required more interesting architecture.
When a conversation gets heated, either participant can activate a 60-second cooldown. Both users see a breathing animation overlay simultaneously. Neither can send messages during the cooldown. After 60 seconds, the conversation resumes.
The tricky part: this needs to be synced in real-time across two devices with minimal latency.
The implementation uses Supabase Realtime channels. When a user activates Breathing Space, the client broadcasts an event on the conversation's channel:
dartawait supabase
.channel('chat:${conversationId}')
.sendBroadcastMessage(
event: 'breathing_space',
payload: {
'activated_by': currentUserId,
'started_at': DateTime.now().toIso8601String(),
'duration_seconds': 60,
},
);
The receiving client listens for this event and immediately shows the overlay. Both clients run independent 60-second timers. There's a 5-minute cooldown between activations to prevent abuse.
The interesting edge case: what if one client has a slightly different clock? We use the started_at timestamp from the activating client and compute the remaining time on receive. If the receiving client gets the event 2 seconds late, it shows 58 seconds remaining. Close enough for a breathing exercise.
Real-time messaging architecture
Since I'm here, let me share the broader messaging architecture because other Flutter devs might find it useful.
Kindly uses Supabase for everything: auth, database, realtime, and storage. The chat system works like this:
Messages are stored in a PostgreSQL table with standard fields: id, conversation_id, sender_id, content, message_type, created_at. Nothing unusual there.
Real-time delivery uses Supabase Realtime's Postgres Changes listener. When a new row hits the messages table, all subscribed clients receive it instantly:
dartsupabase
.channel('messages:${conversationId}')
.onPostgresChanges(
event: PostgresChangeEvent.insert,
schema: 'public',
table: 'messages',
filter: PostgresChangeFilter(
type: PostgresChangeFilterType.eq,
column: 'conversation_id',
value: conversationId,
),
callback: (payload) {
final message = Message.fromJson(payload.newRecord);
_addMessageToState(message);
},
)
.subscribe();
Read receipts use a separate broadcast channel. When a user opens a conversation, the client broadcasts a read event with the last message ID. The other client updates the UI accordingly. This avoids writing to the database on every read — we batch-update read status every 30 seconds.
Typing indicators are pure broadcast — no database persistence at all. One client broadcasts typing: true, the other shows the indicator. After 3 seconds of no typing broadcast, the indicator disappears.
Online presence uses Supabase Realtime Presence. Each client tracks itself with a last_seen timestamp. The green dot on avatars updates in real-time.
The Warmth Score: a reputation system that actually works
Most social apps use follower counts or like totals as reputation. These are easily gamed and don't reflect character.
Kindly uses a Warmth Score — a single number from 0 to 100 that reflects how you treat people. The scoring is straightforward:

Create a pulse (our version of stories): +2
Receive a reaction on your pulse: +2
Someone fully views your pulse: +1
Add a new contact (both sides get it): +3
Get blocked by someone: -10
Inactivity decay: -1 per day after 3 days of no positive activity

The score updates in real-time via a database trigger. When the underlying events happen, a PostgreSQL function recalculates the score and the client's Realtime subscription picks up the change.
What makes it interesting is the decay mechanic. If you stop engaging positively, your score drops. Not as punishment — but as a signal that this person hasn't been active recently. It creates a gentle incentive to show up and be kind, rather than a pressure to post content.
Pulses: stories with a philosophy
Our content format is called Pulses. They're similar to stories but with two key design decisions:
Expiry control. The creator chooses how long their pulse lives: 1 hour, 6 hours, 12 hours, 24 hours, or 7 days. This isn't just a product feature — it required implementing a scheduled cleanup job in Supabase. We use a pg_cron extension to run a deletion query every hour that removes expired pulses and their associated media from storage.
Mindful Timer. Before you can react to someone's pulse, you must view it for a minimum duration based on content length. A text pulse requires 3 seconds of viewing. A photo pulse requires 2 seconds. The timer runs client-side, and the react button stays disabled until the timer completes.
This one design decision eliminated low-effort engagement. When reacting requires actually consuming the content first, the reactions that do come through carry real weight.
Visibility tiers
Every pulse has a visibility setting: Everyone, Contacts, Close, Core, or Only Me. The interesting technical bit is how this maps to Row Level Security in Supabase.
Each visibility tier maps to a different RLS policy that checks the relationship between the viewer and the pulse creator. The "Core" tier, for example, checks a separate contact_tiers table where the creator has explicitly marked specific contacts as Core.
sqlCREATE POLICY "Core visibility" ON pulses
FOR SELECT USING (
visibility = 'core' AND (
auth.uid() = user_id OR
EXISTS (
SELECT 1 FROM contact_tiers
WHERE contact_tiers.user_id = pulses.user_id
AND contact_tiers.contact_id = auth.uid()
AND contact_tiers.tier = 'core'
)
)
);
This means the database itself enforces who can see what. The client doesn't need to filter — it just queries and RLS handles the rest.
What I'd do differently
If I started over, a few things I'd change:
State management. I used Riverpod, which works great, but the learning curve for new contributors is steep. For a messaging app specifically, a simpler approach with ChangeNotifier and streams might have been easier to reason about.
Offline support. I should have built offline-first from day one. Adding it retroactively to a real-time app is painful. If you're building a chat app, use a local SQLite database as the source of truth and sync with the server in the background.
Media handling. Uploading images and videos to Supabase Storage works fine, but I wish I'd implemented progressive upload and thumbnail generation earlier. Users on slow Malaysian mobile networks notice when a 5MB photo takes 8 seconds to send.
Try it
Kindly is live on Google Play. If you're interested in the intersection of communication technology and emotional design, give it a try.
If you're a Flutter developer building real-time features with Supabase, I'm happy to answer questions in the comments.

Download:https://play.google.com/store/apps/details?id=com.kindly.kindly&pcampaignid=web_share