Forem: Jit Chakraborty

I wasted 20 days debugging Capacitor SQLite — turns out it was basically dead

Jit Chakraborty — Sun, 05 Apr 2026 18:27:56 +0000

This one was painful.

I was integrating SQLite into my app (EchoId), and like most people in the Ionic/Capacitor ecosystem, I went with Capacitor SQLite. Seemed like the obvious choice.

Big mistake.

The problem

Nothing worked properly.

random failures
inconsistent behavior across devices
methods not behaving as expected
docs that didn’t match reality

At first, I assumed it was my fault. Misconfiguration, bad setup, something subtle.

So I did what every dev does:

reinstalled everything
rewrote integration multiple times
tried different versions
followed every tutorial I could find

Still broken.

The worst part

There was no clear information anywhere.

Documentation was outdated
GitHub issues were vague or unanswered
StackOverflow had half-answers

Even AI tools (yes, including ChatGPT) kept suggesting:

“maybe try this”
“maybe it’s that”

Nothing concrete. Just guesses.

What was actually going on

After ~20 days of digging, I found the real issue:

👉 The plugin was effectively deprecated / not properly maintained at that time

Not clearly stated.
Not documented properly.
Just silently… unreliable.

That’s why nothing made sense.

The decision

At that point, I stopped trying to “fix” it.

Switched to:

👉 Cordova SQLite

Also, credit where it’s due — big respect to the original author (@jepiqueau) for the work and contributions.

Yeah, older.
Yeah, less “modern”.

But guess what?

It just works.

Result

Stable database operations
Predictable behavior
No random failures
No wasting days debugging ghosts

EchoId still uses it today — and it runs perfectly.

What I learned

Don’t assume the popular option is stable
If something feels fundamentally broken, it probably is
Docs + ecosystem health matter more than “modern stack”
Know when to stop debugging and switch tools

The plugin has since been moved to the Capgo organization, and from what I’ve seen it might be in a much better state now.

But back then? It was a black hole.

If you’re stuck in a loop where nothing makes sense — step back and question the tool itself.

Sometimes the bug isn’t in your code.

If you're building real-time or offline-first apps and have dealt with similar issues, I’d like to hear what you ended up using.

WebSockets Can Stall Without Disconnecting — And It’s Worse on Android

Jit Chakraborty — Sat, 21 Mar 2026 16:45:01 +0000

While building a real-time messaging system, I ran into something frustrating:

The WebSocket shows “connected”… but nothing works.
No errors.
No disconnect event.
No messages going through.
Just a connection that looks alive — but is effectively dead.

The Problem

On Android (especially Chrome and background scenarios), WebSockets can silently stall when:

Network switches (WiFi → Mobile)
App goes into background
Device enters power-saving mode

The connection stays OPEN, but:

messages don’t send
no events are received
no onclose or onerror fires

From the UI → everything looks fine
From reality → it’s broken

What “Connected” Actually Means

WebSockets only tell you:

“The connection is open”
They don’t guarantee:
“The connection is still usable”

Here’s a typical example — the socket is technically connected:

But this state alone doesn’t tell you if data is actually flowing.

What Doesn’t Fix It

A common approach is:

“If the same user reconnects, replace the old socket”
That helps with duplicate connections, but not this issue.
Because here:

the user never reconnects
the connection just stalls silently
What Actually Works

Heartbeat (Ping/Pong)

Instead of trusting the connection, verify it.

setInterval(() => {
socket.send(JSON.stringify({ type: "ping" }))
}, 5000)

The server responds with a pong.
If that stops → the connection is dead.

Track Activity

Keep track of the last message received:

if (Date.now() - lastMessageTime > TIMEOUT) {
socket.close()
reconnect()
}

If no activity → force reconnect.

Don’t Wait for onclose If you rely on:

onclose
onerror
You’ll miss silent failures.
Why This Matters

The worst part about this issue:

It doesn’t break loudly — it fails silently.
Which means:

users think they’re connected
messages don’t arrive
debugging becomes painful

Curious if others have hit this — especially on Android — and how you handled it.

Using AI on a 15,000+ Line Codebase Is Broken (Unless You Do This)

Jit Chakraborty — Fri, 20 Mar 2026 09:42:29 +0000

I tried using AI on a 15k+ line codebase. It failed badly. Wrong changes, broken logic, random imports — classic. Then I changed how I used it, and it started saving me weeks of work.

The Problem

AI doesn’t understand large codebases. You can’t just paste a repo and say:

“refactor this”
It will:

miss dependencies

break existing flows

hallucinate logic

touch things you didn’t ask for
I learned this the hard way.

The Setup

This is not a small project.

Multiple screens, services, storage layers — not something AI can “just understand”.

What Actually Worked

Stop dumping the whole codebase

Instead of:

“Here’s my project, fix X”
Do:

give only relevant files

explain relationships manually
AI is not context-aware at scale. You have to simulate context.

Give strict instructions (like a junior dev)

Bad:

“Improve this”
Good:
“Modify this function only. Do not change API shape. Do not touch unrelated files.”
The difference is massive.

One change at a time

Don’t do:

“Refactor this entire flow”
Do:
break into small steps
verify each change
then move forward
AI works best iteratively, not in one shot.

Expect it to fail so always keep backup

It will:

generate wrong logic
miss edge cases
introduce bugs
Example:

This is where you review like a senior — not trust blindly.
The Real Insight
AI didn’t replace my work. It compressed months into days, but only because I guided it properly. If you treat AI like magic, it breaks. If you treat it like a junior dev, it becomes powerful.
Final Thought
AI is not bad at large codebases. Most people are just bad at using it correctly. If you're working on bigger projects, stop prompting lazily. That’s the real bottleneck.

How EchoId Actually Handles Privacy

Jit Chakraborty — Wed, 18 Mar 2026 18:02:15 +0000

Most “privacy-focused” messaging apps still collect metadata.

Even if messages are encrypted, servers often know:

who you talk to

when you talk

how often

That’s still surveillance.

So while building EchoId, I focused on reducing what the system can know.

Core Approach

Instead of building a “smart” backend, I kept the server dumb.

It only acts as a relay.

No storage. No analytics. No logging of messages.

If there’s nothing stored, there’s nothing to leak.

Encryption

Messages are encrypted using AES before being sent.

This means:

Server never sees plaintext

Messages are unreadable in transit

Even if intercepted, they’re useless without the key

Server Design

The backend does only 3 things:

Accept message payload

Forward it to recipient

Drop it

No database for messages. No history.

What This Solves

No message analysis

No stored conversations

Reduced metadata exposure

No user profiling

What’s Still Hard

This doesn’t magically solve everything.

Challenges I’m still working on:

Key exchange (secure + simple)

Preventing abuse without tracking users

Handling offline delivery without storage

Scaling relay without introducing logs

Philosophy

Privacy isn’t about adding encryption.

It’s about removing the ability to collect data at all.

EchoId is still early, but the direction is clear:
Less data > more protection

Repo

https://github.com/fabulousman12/echoid-open_source

buildinpublic #privacy #opensource

dev challange

Jit Chakraborty — Mon, 16 Mar 2026 10:47:31 +0000

Why Privacy Matters in Messaging

Jit Chakraborty — Mon, 16 Mar 2026 10:34:59 +0000

Most modern messaging apps put ease of use first, but privacy is often not as important. A lot of services keep track of not just the content of your messages, but also metadata like who you talk to, when you send messages, and how often you talk to them.

This information can tell you a lot about a person's life and relationships, even if you don't read the message itself.

This means that privacy shouldn't be an afterthought. It must be included in the design of the system from the start.

Encrypting Messages

Before being sent over the network, messages in my project EchoId are encrypted.
The Advanced Encryption Standard (AES) is used by the system to encrypt the message itself.

AES is a symmetric encryption algorithm, which means that the same key is used to encrypt and decrypt data.

This is what the basic process looks like:

An AES key is made at random.

That AES key is used to encrypt the message.

RSA encrypts the AES key itself.

The encrypted key and message are sent together.

People often call this method "hybrid encryption."

What is the purpose of this design?

AES is a very fast way to encrypt message data.

RSA is used to safely share the AES key.

This lets messages stay encrypted while still being sent quickly.

What This Means

In simple terms, the message you send is converted into unreadable data before it leaves your device. Only the intended receiver, who can decrypt the AES key, can turn that data back into the original message.

The goal is to ensure that even if the network or server is compromised, the message content itself cannot be read.

Final Note

This is something I’m currently experimenting with while building EchoId, a privacy-focused messaging system exploring encrypted communication and WebRTC-based calls.
Open source:
https://github.com/fabulousman12/echoid-open_source

I built EchoId – a privacy-focused messaging app with encrypted chat and voice calls

Jit Chakraborty — Sun, 15 Mar 2026 15:00:13 +0000

I built EchoId – a privacy-focused messaging app with encrypted chat and voice calls

I recently built EchoId, a personal project exploring secure communication and privacy-focused application design.

The idea behind the project was simple: create a messaging platform that avoids analytics, tracking scripts, or behavioral profiling. It’s not a company or commercial product — just an independent project I built while experimenting with encryption and realtime communication systems.

Features

Encrypted messaging
Voice calls using WebRTC
No analytics or tracking
Lightweight backend designed for simple communication

The project is still evolving, and I’m mainly interested in feedback from developers and privacy-minded users.

If anyone is interested in the architecture, encryption approach, or implementation details, I’d be happy to discuss them.

Project website:
https://echoidchat.online

Open source repository:
https://github.com/fabulousman12/echoid-open_source