jchrisa

Damn I just deleted another 29k loc https://github.com/VibesDIY/vibes.diy/pull/635

Code slows you down, always worth cleaning up. Yes, the business case is aligned with both the past bloat, and the current cleanup.

I just had a majorly fun time addressing tech debt, deleting about 15k lines-of-code from a codebase that now has ~45k lines of implementation, and 50k lines of tests. This was made possible by moving from a homegrown auth system to Clerk, as well as consolidating some Cloudflare workers, and other basic stuff. Not as fun as creating the tech debt in the first place, but much more satisfying. Open source repo if you like to read this sort of thing: https://github.com/VibesDIY/vibes.diy/pull/582

I just vibed up a quick and dirty catalog browser for FedFlix -- thanks IA for making the API so easy to use!

https://unknown-ptarmigan-3137.vibecode.garden

Click the remix button in the bottom right and you can make it your own.

The generation is running while you login, so this appreciable decreases wait time from idea to app, because by the time you click through the login, your app is ready. (Vibes DIY CEO here.)

If login takes 30 seconds, and app gen 90, we think this is better for users (but clearly not everyone agrees.) Thanks for the feedback!

I haven't posted it here yet b/c it's not show ready, but we have been building this vision -- I like to think of it as an e-bike for the mind.

https://vibes.diy/

We had a lot of fun last night with Vibecode Karaoke, where you code an app at the same time as you sing a song.

This is very much like Erlang's actor model. The same compute can be run in parallel, or managed via queues. With Erlang's strong support for FFI and process control, I wonder if it's being used as a dispatcher for these sorts of workloads.

if there is an ideological bent, or other driving reason -- write it up! make treatise / requirements document for someone else to implement.

Some discussion on the repo README: https://news.ycombinator.com/item?id=42383592

I'm curious what your environment looks like. We have a bunch of open source options, but standing up a new one is always getting easier.

I didn't say enough about the ledger-like aspects above. Some databases have collections, some have tables, Fireproof has ledgers. These are the unit of sharing and access control, and also the unit of provable history.

The best starter is the React Tutorial in our docs: https://use-fireproof.com/docs/react-tutorial/

We are updating this example to the latest right now, it shows how team chat can be implemented with database sharing. https://github.com/fireproof-storage/firehouse-chat

This drum machine is pretty forkable as well: https://github.com/fireproof-storage/bloopernet

You can also get started by clicking the "Edit in CodePen" button on our home page, which is just a JavaScript and HTML app.

Thanks -- we got hello world with Socket, but there's some interesting open source work we'll need to do to support peers acting as servers and take full advantage of the network.

https://github.com/fireproof-storage/hello-socket-fireproof

If anyone wants to join the effort, the semantics we are talking about are also aligned with WebRTC delivery, so you'd enable a bunch of p2p topologies with your contribution.

Here are some apps people have built, for inspiration:

* Bloopernet Drum Machine: https://news.ycombinator.com/item?id=42177005

* Slack style team chat https://firehouse-chat.jchris.partykit.dev/

* PartKit Cloudflare https://blog.partykit.io/posts/fireproof-database-connector

Here is the code sample I mentioned, example React usage (see our homepage for Vanilla JS)

    import { useFireproof, useDocument } from "use-fireproof";
    import { connect } from "@fireproof/cloud";

    export default function App() {
      const { database, useLiveQuery } = useFireproof("my_db");
      connect(database, "my-remote");
      const { docs } = useLiveQuery("_id");

      const [newDoc, setNewDoc, saveNewDoc] = useDocument({ input: "" });

      const handleSubmit = async (e) => {
        e.preventDefault();
        if (newDoc.input) {
          await saveNewDoc();
          setNewDoc({ input: "" }); // Reset for new entry
        }
      };

      return (
        <div>
          <form onSubmit={handleSubmit}>
            <input
              value={newDoc.input}
              onChange={(e) => setNewDoc({ input: e.target.value })}
            />
            <button>Add</button>
          </form>
          <ul>
            {docs.map((doc) => (
              <li key={doc._id}>{JSON.stringify(doc)}</li>
            ))}
          </ul>
        </div>
      );
    }

Fireproof embeds in the browser, so you can add it to frontend code just like any other JavaScript module. It's useful for app data even without a backend.

When you are ready to connect multiple users, that's when the backend comes in, which can be as simple as Fireproof Cloud or your existing AWS account.

Thanks for reading — Fireproof creator here, happy to answer any questions.

We are in-flight on our cloud launch, so consider it a preview of the experience we are building. We’ll soon be shipping more complete authorization with UCAN capability delegation, and we are working on mature key rotation. I can't wait to hear what people want to build with it.

Thanks for sharing -- the author runs a synth themed bike ride in Portland, and we worked together on a drum machine participants can use to keep time in addition to the synths and amps the usually bring.

It uses the collaborative live database we are working on at Fireproof -- I hope the folks here like this sort of application model. If you have feedback we are listening.

CouchDB's HTTP API used to fit in just one file (less than 1k lines of Erlang), and it was a great jumping-off point for learning databases and web programming: https://github.com/apache/couchdb/blob/0.8.1/src/couchdb/cou...

It was written by one engineer, and then later refactored by a team to look like this (and many other files): https://github.com/apache/couchdb/blob/main/src/chttpd/src/c...

It's an interesting exercise to see how something grows and changes as it transitions from inspiration to real-world usage.

It's smart because you have deep control of bugwards compatibility, and can swap parts of the stack later.

This seems like a textbook case where AI could let you have your cake and eat it too. Eg work in the easy 2d domain with maybe unstructured sticky notes. have a deterministic pipeline from 2d to geometric checking, with I guess patch points for the manual stuff. and then have AI draw up and maintain the BIM. It seems tailor made to copilot those adhd tasks you describe.

If you want to read about another implementation using Merkle CRDTs for practical local-first document database storage, I've been building a new database for about a year. I plan to share more but it's definitely an example of a Merkle CRDT, inspired by a lot of the same research in the Dolt paper.

Architecture - https://use-fireproof.com/docs/architecture CRDT file format - https://fireproof.storage/posts/remote-access-crdt-wrapped-m...

P2P connection in the runtime will make a huge difference for apps - outside pressure like this (and React Native) is what ultimately drives the web platform forward.

It's cool because Erlang's functional design means F() is just as good a "top-level" context as whatever one you were in before. Eg this will smoothly allow existing requests on the old logic but start new requests on the new logic, and eventually allow the old logic to be GC'd.

I am building a new immutable cryptographically verified database using IPLD data structures and prolly trees. This allows changes made anywhere to be transparently synced, and for operations to be commuted amongst untrusted peers, for instance allowing for shared index maintenance.

https://use-fireproof.com/docs/architecture

It's also the easiest way to write React apps. Here are some ChatGPT expert builders that I've trained to use the CSS framework of your choice with Fireproof: https://use-fireproof.com/docs/chatgpt-quick-start/#react-ex...

I ran this game on the local political establishment in 2015, and it was scary effective. I assume they are more resilient today, but at the time entry-level social media advertising techniques were able to have a massive influence on politician's perceptions of their constituents's concerns. I wasn't surprised at all by the impact social advertising ended up having in the 2016 election.

The USA has ~20 million empty homes, according the census. Three people per house is all it takes to equal China's number.