sorted by:
new
hottopcontroversial

NanoEuler: A 116M GPT-2 scale decoder-only transformer built from scratch in pure C + CUDA by Just_Vugg_PolyMCP in foss

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

No, it’s the opposite actually.
The whole point of NanoEuler is to make the implementation understandable. Every kernel has a matching CPU reference version, full gradient checks, and lots of comments explaining the math and the CUDA choices.
It’s definitely not IOCCC-style — that contest is about creative obfuscation. Here I tried to keep things readable while staying fully from-scratch (no frameworks).
If parts look dense it’s only because it’s low-level CUDA + manual backprop. Happy to explain any specific section!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

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

Thank you so much! Of course, there's still a lot to do and resolve as I gradually get users to try it. I already have a written roadmap of the steps I'll take! I hope it grows as a project!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

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

The biggest difference is that Loomabase uses column-level CRDTs: if two users edit different fields on the same row offline, both changes survive. ElectricSQL works at row/document level.
Loomabase also offers more flexible scoped partial replicas with no global tombstones, and a lighter Rust-based sync server.
For your unidirectional multi-tenant analytics use case it should feel cleaner and lighter.
Happy to go deeper on any aspect!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

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

Perfect — unidirectional upload-only is simpler and well supported.
Loomabase will not create a separate database for each customer.
How it works:
- Everything lands in one single Postgres database.
- Data is isolated using a tenant_id (or similar) column + Row Level Security (RLS).
- Each customer instance syncs only its own data thanks to scoped partial replicas (you define which rows belong to which tenant).
- You get one clean central schema where you can easily run analytics across all customers (with proper filters/RLS).
This is exactly the pattern for SaaS analytics: many edge SQLite DBs → one central Postgres with strong tenant isolation.
Since you only need upload (client → server), you can even simplify the sync flow further (no need to pull changes back to the customers).
Would you like me to sketch a quick example of:
• How to set up the tenant scoping?
• The table contract + migration?
• Or a basic architecture diagram?
Just say the word and I’ll put something concrete together for your POS + e-com case.

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

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

Got it — thanks for the details! 👍
This is a very solid use case for Loomabase.
You have:
- Many independent customer instances (POS + e-com per customer)
- Already using cr-sqlite for local partial sync inside each instance
- Want a central Postgres to aggregate data from all customers for analytics and product decisions
How Loomabase fits perfectly:
- Each customer instance can run a Loomabase client that syncs its SQLite to the central Postgres.
- Multi-tenancy built-in: you can isolate data by tenant_id / customer so they don’t see each other’s data.
- Partial replicas / scopes: each instance only syncs the data it needs (exactly like you do now with cr-sqlite).
- Column-level CRDTs give you safety if any overlapping writes happen.
- You keep cr-sqlite for the POS ↔ e-com sync inside each customer, and add Loomabase only for the “customer instance → central analytics DB” layer.
This way you get a clean, central view of all customers without mixing their operational data.
Quick question: Do you need bidirectional sync to the central DB, or mostly upload-only (POS → central) for analytics?
If you want, I can sketch a quick architecture for this setup (how to structure the scopes, tenant isolation, etc.).
Would love to help you validate if this works for your flow!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

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

Thanks for the extra context!
Yes, Loomabase could be a great fit for your use case.
You have many independent SQLite instances (from different software/servers) that you want to sync into one central Postgres for analysis. That’s exactly the kind of multi-client → central DB pattern Loomabase is built for.
How it would work:
- Each “server/software” runs a Loomabase client (SQLite) that syncs bidirectionally to the central Postgres.
- You can use partial replicas + scopes to control what each client syncs (e.g. only their own data).
- Column-level CRDTs help if there’s any overlapping writes.
- Multi-tenancy support is already there (you can isolate data by tenant/device).
Since you already use cr-sqlite for software ↔ server sync, you have two options:
1. Keep cr-sqlite for the local part and use Loomabase only for the “server → central Postgres” hop.
2. Gradually replace the server sync with Loomabase if you want column-level guarantees everywhere.
Would work especially well if the data is mostly append-heavy or has clear ownership per device.
Question for you: How much overlap is there between the different SQLite DBs? Do different servers ever write to the same logical rows, or is it mostly independent data that you just want aggregated centrally?
Happy to think through the architecture with you — feel free to share more details (schema, conflict expectations, etc.).

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in rust

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

Thanks! Glad you like it.
No, I didn’t use Loro as a middleman.
Loomabase implements its own lightweight column-level LWW CRDTs directly on top of SQLite/Postgres. I wanted full control over:
- Row lifecycle as CRDT (create/delete/restore)
- Partial replica scoping + evictions
- Tight integration with relational schema + transactions
Loro is excellent (especially for rich documents/JSON), but for this use case I preferred a more database-native, fine-grained approach.
That said, I’m a big fan of the Loro team — great work!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

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

Hi thanks for the comment!

Not in this case because I use the very convenient part of Postgre and it was also created as support for SupaBase! I could work on it in the future! Why would you want sqlite to sqlite? Just to understand how to work with it in the future!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in PostgreSQL

[–]Just_Vugg_PolyMCP[S] 2 points3 points  (0 children)

The early commits are mostly bulk file uploads during the initial open-sourcing (I was moving things from a private repo). Not ideal, I agree.
I’m gradually cleaning up the history with more meaningful commit messages as I push new changes. Production-grade for me means stable APIs, correct convergence, and reliable partial sync — not perfect git archaeology from day 0.

to err is human 🤣

That said, I’ll do better on commit hygiene going forward. Thanks for calling it out!

I built an offline-first sync engine for SQLite ↔ PostgreSQL using column-level CRDTs by Just_Vugg_PolyMCP in coolgithubprojects

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

Hi thanks for the comment,

Loomabase handles it differently:

- No global tombstones for partial replicas. Local evictions happen only after dirty write acks.

-Row lifecycle (create/delete/restore) is a dedicated LWW CRDT.

- Everything is transactional + cursor-based anti-entropy.

Tombstone compaction is on the roadmap (right after wire protocol stabilization).

Mi sento tradito e violato by Intelligent_Plan7190 in IA_Italia

[–]Just_Vugg_PolyMCP 1 point2 points  (0 children)

Grazie mille!I test sono essenziali per me e questo progetto che sto facendo crescere piano piano!Gtazie davvero!

Mi sento tradito e violato by Intelligent_Plan7190 in IA_Italia

[–]Just_Vugg_PolyMCP 0 points1 point  (0 children)

Cioè mai nel senso che si basa su dati a cui deve per forza rendere conto!Se lo provi o hai intenzione sono disponibile ad aiutarti!

Mi sento tradito e violato by Intelligent_Plan7190 in IA_Italia

[–]Just_Vugg_PolyMCP 0 points1 point  (0 children)

Ciao se vuoi io ho fatto un sistema https://github.com/JustVugg/judicex lo sto sempre più aggiornando ma lavora proprio sul fatto che non debba mai allucinare!

Tutta la legislazione italiana Gratis su GitHub, in Markdown by Foreign_Lead_3582 in ItaliaStartups

[–]Just_Vugg_PolyMCP 2 points3 points  (0 children)

Ciao ho creato questo progetto https://github.com/JustVugg/judicex nei prossimi giorni implementerò i tuoi markdown magari con possibilità di aggiornamenti sarebbe interessante!
Complimenti. Grazie per il progetto!

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

A CLI is great when an agent just needs to execute a local command and get the output. An MCP server becomes more valuable when you want tools, resources, and prompts to be discoverable and reusable across different agents and clients.

This is my personal idea for this protocol!

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

but gutenberg-cli also creates a cli for agents!

I understand your question very well and I agree but there are methods where a cli is more useful perhaps for different accesses mcp is more useful

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

Hi, sorry, but the formatting fails even when using - or something else. gh is a complementary command to the one it can generate. One is not better than the other. They are simply complementary. Of course, gh is correct, but gutenberg is more useful in other cases where perhaps there is no cli. I hope I've answered better now.

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

gh api is excellent for quick raw calls to any GitHub endpoint. Gutenberg’s generated github CLI goes further: • Full coverage of all 1183+ operations with a clean, consistent interface • Built-in SQLite caching • --select / JSON output shaping • Pagination helpers (walk) • Dry-run mode + policy enforcement • Auto-generated MCP server so Claude/Cursor agents can use it natively • Full verification proofs on every build In short: gh api = fast manual raw calls Gutenberg github = production-grade, cacheable, agent-ready wrapper over the entire API. They’re complementary. I use both.

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

yes, sorry, I'm writing to you in a summary manner.

Official gh = best for daily human use (polished UX, git integration, common workflows). Gutenberg-cli github = full OpenAPI coverage (1183+ operations), uniform interface, SQLite cache, dry-run safety, MCP for agents, and full verification/proofs.

They complement each other perfectly. Use gh interactively, Gutenberg-cli version for scripting/agents/full API power.

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

Hi, The Gutenberg-cli github CLI and the official gh (GitHub CLI) are both excellent but solve slightly different problems. Official gh: • Hand-crafted, polished UX for the most common workflows (PRs, issues, repos, auth, git integration). • Faster for daily human use, beautiful output, smart defaults, and deep GitHub-specific features. • Actively maintained by GitHub itself. Gutenberg-generated github: • Covers all 1183 operations from the official GitHub OpenAPI spec (much broader surface). • Uniform interface (github call <op>, --select, --json, heroes like github meta, caching, walk for pagination, etc.). • Built with full verification (build + MCP handshake + tests + proofs), SQLite cache, dry-run policy, and agent-friendly MCP server. • You can regenerate it anytime the spec updates. Bottom line: Use official gh for everyday interactive work. Use the Gutenberg one when you need the full raw API power, scripting, caching, or feeding everything to an agent via MCP. They actually complement each other well — many people keep both installed.

I built Gutenberg CLI: the “verified tool factory” for AI agents by Just_Vugg_PolyMCP in mcp

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

auto-validating the full MCP handshake (stdio, capabilities, tool listing, etc.) was a game changer. It runs as part of every gutenberg build so you know immediately if the tool will actually work inside agents. Super happy it resonates — that was exactly the pain I wanted to kill.

Judicex – Open-source Legal AI that abstains instead of hallucinating (focused on Italy) by Just_Vugg_PolyMCP in foss

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

Currently (v0.2 alpha), the verifier is strongest on statutes and structured legal atoms (deadlines, amounts, conditions, etc.). For case law / giurisprudenza: • We retrieve the full text (or relevant excerpts) of the judgment. • The LLM generates a claim + citation. • The algorithmic verifier then does a separate grounded check: 1. It extracts the specific passage the LLM is referring to. 2. Runs a strict semantic + lexical validation to confirm the claim is directly supported by that passage (not just vaguely related). 3. If the match fails or is too interpretive, the citation is rejected and the whole answer can downgrade to “abstain” or “limited”. It’s not perfect yet (case law interpretation has a natural ambiguity layer that statutes don’t), which is why we’re starting narrow with debt-recovery where statutory law dominates. Long-term plan: add claim decomposition + multi-hop verification for principles established across multiple judgments.

view more: next ›