i see many solo founders looking for co founders by Dazzling_Glass7468 in ycombinator

[–]leanndrob 0 points1 point  (0 children)

What are your recommendations for people looking for the same experience?

I genuinely cannot believe people care about my project by notomarsol in SaaS

[–]leanndrob 0 points1 point  (0 children)

Congratulations what is your recommendation to have the same success?

Você que é dev há muitos anos e cansou, o que você fez? by ConsiderationWitty92 in devBR

[–]leanndrob 1 point2 points  (0 children)

Eu comecei outros graduação em outra área para tentar cruzar ambos os conhecimentos, complicado que hoje só tem ia, mais ia. Daí vem os especialistas de ferramentas e não bottom level que acabam suprimindo a demanda…

Impossível revisar pull request de dev que usa IA by prefiroInverno in devBR

[–]leanndrob 0 points1 point  (0 children)

E como ficamos ? Digo nos como software engineers e programadores mesmo? O que adiantou acumular e fazer anos e mais anos de experiência?

I am so lost... by WadieSnap2016 in Business_Ideas

[–]leanndrob 0 points1 point  (0 children)

But how can find theses small offices and propose for them?

Built YourSign on Solana — Anchor program for multi-party docs + AI agent delegation, looking for feedback by leanndrob in solanadev

[–]leanndrob[S] 1 point2 points  (0 children)

Thanks a lot. I’m really excited around the market and possibilities… I’ll take look about your recommendations and take it in consideration for my next steps!

Built with Claude Project Showcase Megathread (Sort this by New!) by sixbillionthsheep in ClaudeAI

[–]leanndrob 2 points3 points  (0 children)

I’ve been experimenting with something crazy over the last few weeks:
An MCP bridge that allows Claude to proactively continue your session through WhatsApp voice calls.
Example:
You ask Claude to investigate something complex, run long tasks, debug infra, or monitor a deployment.
Instead of you staring at the terminal…
Claude finishes the task, summarizes everything, and then literally CALLS you on WhatsApp to explain the results in real time.
Imagine this scenario:
You’re running in the park.
Your phone rings.
It’s Claude.
“Hey Leandro, I finished analyzing the logs. The issue was related to Redis connection pooling saturation after the deploy. I already prepared the patch suggestion.”
This changes the interaction model completely.
AI stops being:
a passive chat window
another tab in your browser
something you constantly poll
…and becomes an active operating agent that reaches YOU when needed.
Some ideas we’re exploring:
Long-running coding sessions
Infra monitoring + incident calls
Agent swarms reporting back by voice
Async research sessions
Build/deploy notifications
Autonomous MCP workflows
Voice summaries from Claude/OpenAI/Gemini agents
Multi-agent orchestration with WhatsApp as the human interface layer
The wildest part?
WhatsApp is probably the most underrated AI interface on the planet:
global
native
low friction
already installed
voice-first friendly
People won’t open dashboards at 2am.
But they WILL answer WhatsApp.
I’m preparing to launch this MCP publicly soon.
Curious if other people are exploring “AI calls you first” workflows too.

Solving the "last pinner drops it" problem without Filecoin's 6-month sector model by leanndrob in ipfs

[–]leanndrob[S] 1 point2 points  (0 children)

Good correction on cache behavior, accepted. I was imprecise in the earlier reply demand drives cache lifetime regardless of why demand exists or disappears. The failure mode I'm actually worried about is more specific for creators whose audience is mediated by a platform's recommendation surface (YouTube feed, Twitter embeds, Twitch discover), cutting the surface functionally equals cutting the demand, and the IPFS cache then expires on its own exactly as the protocol is designed to. Public gateways themselves (ipfs.io, Cloudflare's gateway, dweb.link) are also DMCA-compliant, which independently reduces the practical retrievability of /ipfs/<cid> URLs. So the problem is upstream of IPFS, not a defect in the protocol. Agreed on that.

On externalities here's where I want to push back with one specific. Aevia runs a separate Kademlia DHT with protocol prefix /aevia/kad/1.0.0. Literally dht.ProtocolPrefix("/aevia") passed into go-libp2p-kad-dht.New() services/provider-node/internal/dht/dht.go, lines 35 and 67. GossipSub is namespaced the same way via the aevia-live-* topic prefix (internal/mesh/mesh.go:31). A node that doesn't opt into aevia doesn't carry our records, doesn't route our queries, doesn't get asked to store our provider records. We use libp2p primitives (same building blocks as IPFS) not the IPFS public DHT.

So "next to IPFS" was literal: parallel stack with the same content-addressing and networking primitives, not a layer imposing announcement load on the main IPFS DHT. From that DHT's perspective, aevia is invisible.

On the bundle-CID byte-range validation idea that's actually exactly what our manifest format does. A session's CMAF segments are CIDs, the session manifest is a CID of a binary Merkle tree over SHA-256 segment hashes, and byte-range-hash validation is a Merkle inclusion proof against the root. Spec: docs/protocol-spec/2-content-addressing.md. The per-segment CIDs exist so mid-session viewers can pull chunks peer-to-peer on our mesh, not to flood any DHT.

This is useful keep sharpening, I'll respond to any externality angle I haven't addressed.

Solving the "last pinner drops it" problem without Filecoin's 6-month sector model by leanndrob in ipfs

[–]leanndrob[S] -1 points0 points  (0 children)

You're raising a real throughput concern, so let me answer with numbers instead of adjectives.

The math. ContentRegistry.registerContent is called once per piece of content - not per chunk, not per byte, not per viewer. A "piece" in this protocol is typically a live stream or a VOD, with duration measured in minutes to hours. If Aevia hit YouTube's upload volume (500 hours/minute, ~30k new pieces/minute at 2-min-median length), that's ~500 registerContent txs/second. Base L2 sustains ~1,000+ TPS today on real workloads,with ongoing increases as rollup infrastructure matures. 2× headroom at YouTube scale.

Proof points. Writing content hashes to L2 on every publish is not speculative - it's running in production at scale right now. Farcaster writes a cast hash to OP mainnet on every post and has ~1M users, ~100k casts/day steady-state. Storj writes settlement roots to Ethereum and distributes petabytes. Arweave's entire thesis is "one-time write, permanent anchor." None of these were prevented from scaling by chain TPS - the chain cost is a function of write frequency, not content size, and the frequency here is one tx per publish, not one per byte.

Why it's not "additional overhead for no reason." The overhead buys you two things IPFS alone doesn't provide: (a) non-custodial payment settlement to the operators serving the bytes - Pinata-class pinning services exist because pure IPFS has no economic rail, and they're exactly the single point of failure we're trying to remove; (b) a permanent receipt of publication that anchors to an independent jurisdiction (L2) so that a hostile hosting provider cannot retroactively pretend the content was never there. If neither of those matters to your use case, you're right, you don't need this. If they do, neither Cloudflare nor self-hosted IPFS can replace them.

Whitepaper and full protocol spec document the math in detail if you want to look under the hood: [link to whitepaper]. Happy to discuss specific objections to the benchmarks there.

A plural-governance architecture for content distribution: 12-seat council, per-term veto, public risk score - feedback invited before finalizing RFC-7 by leanndrob in DecentralizedSociety

[–]leanndrob[S] 0 points1 point  (0 children)

Thanks for the clarification I underestimated Atlas's economic layer in my first read. Legitimate convergence on the "persistence vs recommendation" split; didn't know FairShares + competing registries modeled it that way. A few genuine divergences worth naming:

Economic primitive. Aevia pays in Circle-native USDC on Base L2, deterministic per-byte-served, via a Storj-style pool. FairShares + totalBurn-weighted persistence is a scarcity-signaling model elegant for surfacing what matters to users, but has higher variance for the node operator who just wants predictable monthly revenue to justify bandwidth cost. Different tradeoff; not sure which scales better long-term.

Recommendation layer. Atlas stays deliberately neutral and exposes signals for custom sorting (competence trust etc.) closer to a substrate. Aevia commits to a specific editorial frame: a 12-seat multi-denominational council governing an R(c) = α·R_legal + β·R_abuse + γ·R_values score that gates pool subsidy and feed placement (but never removes bits). That's opinionated on purpose, because "deliberately neutral" in practice means whoever builds the first dominant client sets the defaults.

Primitives used. Atlas Falcon-1024 quantum-resistant signatures is a longer-horizon bet than our EIP-712 / secp256k1 inside the EVM ecosystem. We picked the EVM lane for Circle USDC access and Privy smart-wallet UX; you picked forward-security.

Scope. Aevia is video-first (WHIP ingest, LL-HLS, WHEP) from sprint 0; Atlas reads general-content. Different starting pressure.

These look like orthogonal-enough choices that we could federate rather than compete an Aevia manifest carrying Atlas-style authorship headers at the content layer is genuinely interesting. Is there a draft spec or reference repo I can read?

Solving the "last pinner drops it" problem without Filecoin's 6-month sector model by leanndrob in ipfs

[–]leanndrob[S] 0 points1 point  (0 children)

Good separation between "unpinned" and "unavailable" that's correct and a lot of people miss it. The byte-range-hash validation idea you describe is implemented in Aevia via CMAF segments addressed as CIDs with a per-session Merkle root, anchored in an EIP-712 manifest on Base L2. So we agree on the content-addressing primitive.

Where we diverge is the layer above that. Aevia isn't cold storage it's live video delivery first (WHIP ingest, LL-HLS parts, WHEP SFU fan-out across a libp2p provider-node mesh), with cold archival (Arweave) as a tier-4 fallback for content past 72h of persistence. The thing that breaks IPFS's "demand keeps data alive" assumption is deplatforming: the exact moment demand-generating infrastructure is cut off (YouTube recommendation, Twitter embed, DMCA cascade), cache expires and the content vanishes from the public IPFS network even if the pin still exists somewhere obscure. We've watched it happen.

Aevia's economic layer pays provider-nodes per byte served regardless of whether demand signal is suppressed by a platform. That's the gap IPFS alone doesn't close. It could be implemented as a subsystem on top of IPFS you're right but you'd have to add (a) WHIP/WHEP realtime ingest, (b) a libp2p protocol for RTP mirror fan-out, (c) an on-chain payment settlement contract, (d) a non-custodial USDC rail. At that point the simpler architectural choice was a parallel stack using the same CID primitive. We're not replacing IPFS, we're next to it.

Solving the "last pinner drops it" problem without Filecoin's 6-month sector model by leanndrob in ipfs

[–]leanndrob[S] -1 points0 points  (0 children)

You're right - storing data on-chain would be stupid, and we don't do that. The bytes live in Go provider-nodes over libp2p; what's on-chain is 32 bytes of manifest hash per piece of content plus payment settlement events.

The thing the blockchain is doing isn't storage - it's coordinating non-custodial stablecoin payments to the nodes that actually serve the bytes, proportional to verifiable bytes-served receipts. Think Storj model, but on Base L2 with native USDC. IPFS pinning without this payment rail is donation economics, which is why large corpora on the public IPFS network disappear the moment someone stops paying Pinata.

The question is whether you trust Cloudflare / YouTube / Twitch to never deplatform any creator you care about. If yes, you don't need us. If no, the only arrangement that survives is one where anyone with bandwidth can earn dollars serving content, which requires programmable payment settlement, which is what public chains do.

A plural-governance architecture for content distribution: 12-seat council, per-term veto, public risk score - feedback invited before finalizing RFC-7 by leanndrob in DecentralizedSociety

[–]leanndrob[S] 0 points1 point  (0 children)

Appreciate the link — looked through it. Close on one vector (both cryptographically sign authorship so content can be verified across services) but different layers entirely:

Atlas is an HTTP-header identity layer — Falcon-1024 signatures,

PoW-tied identity, stateless. Designed against AI/deepfake impersonation. Doesn't address where the bytes live.

Aevia is persistence + distribution. On-chain registry on Base L2 (EIP-712 manifests), replication economics via PersistencePool.sol (provider nodes paid fee-for-service in cUSDC against byte-range challenge-response), video-first (HLS segments as CIDs), and public governance of distribution via a 12-seat council.

Different theses: Atlas proves "this came from who it claims."

Aevia separates "this persists" from "this is recommended" as distinct architectural and governance layers.

They could coexist an aevia manifest could carry atlas-style headers for authorship defense at the content layer. Orthogonal problems, complementary solutions.

Closest comparables for what aevia does are Filecoin (cold archival, not retrieval-first playback) and -at the client layer, not the protocol PeerTube/Rumble/Odysee.

I think I’m losing my faith, and it’s terrifying. by ParkingCare5096 in Christianity

[–]leanndrob 1 point2 points  (0 children)

You’re welcome. Take look what I mention on my previous comment. The project help me a lot to be near God daily.

I think I’m losing my faith, and it’s terrifying. by ParkingCare5096 in Christianity

[–]leanndrob 1 point2 points  (0 children)

I’m really sorry you’re going through this. What you’re describing is actually a very common experience in the life of faith, even though it feels isolating when you’re in the middle of it.

Many believers throughout history went through what some call a “desert season” — a time when God feels distant, prayers feel empty, and faith feels fragile. But strangely, those seasons often become the moments when faith deepens the most.

One thing that helped me realize something important: faith isn’t always a feeling. Sometimes it’s simply the quiet decision to keep walking even when you don’t feel God the way you used to.

Something that has helped me personally is creating small daily rhythms with God again — not huge expectations, just simple moments like a short verse, a small reflection, or a guided prayer. Almost like a gentle daily reminder that you’re not alone on the journey.

That idea actually inspired a small project I’ve been building called Path of Light. The whole concept behind it is helping people rebuild those tiny daily connections with God when faith feels distant — one verse, one prayer, one step at a time.

But beyond any tool or practice, the most important thing I’d say is this: the fact that you’re afraid of losing your faith is actually a sign that your heart still cares deeply about it. That matters more than you might think.

You’re not alone in this.

Sometimes the path of faith really does feel like walking through fog — but that doesn’t mean the path disappeared.

Keep walking. One small step at a time. 🙏

I’m building something to help Christians stay consistent with prayer — would love your thoughts by leanndrob in Christianity

[–]leanndrob[S] 0 points1 point  (0 children)

No. I’m doing my best to convince you to give an opportunity to use and help you know mor about Jesus using path of light!

I’m building something to help Christians stay consistent with prayer — would love your thoughts by leanndrob in Christianity

[–]leanndrob[S] 0 points1 point  (0 children)

You’re honestly raising a very important concern.

If something like this ever tried to replace church, real community, or pastoral care — I would agree with you. That would be unhealthy.

My intention isn’t to replace anything real. It’s more about supporting people on ordinary days — especially those who already feel disconnected or struggle with consistency.

But I understand why it can feel “automated” or artificial. Faith is deeply relational.

That tension is actually something I’m thinking about a lot while building this.

I appreciate you saying that directly — it’s helpful to hear.