Cool stuff! How did you do it?

#gm #asknostr What did Santa bring you this year?

#asknostr #portugal #gig Looking for some data about Uber rides in Portugal. I'm paying 0.60 eur per valid receipt. Constraints: * Must have been a ride in Portugal (and completed) * Must have been in the last 3 months (> 2025-09-01) * Must have costed more than 10 eur How to submit: Fwd the trip receipt to [email protected] alongside with a lightning address or npub. Once I validate the data I'll send you the satoshis! Questions, just drop them here :)

#vibecoding This month I've been trying out venice.ai Pretty cool service. You get to try a bunch of different open source models with a pretty slim UI (not that clunky hugging chat). Kimi, GLM and even their version of Mistral's latest. The promise is still uncensored AI and privacy focused AI; they are almost there (all models are just using other inference providers) but it's pretty good to try.

I don't think you will throw it all out afterwards. It is still a good thing to keep and prototype on as you evolve. The main drawback I see on replit: it skews you into using their infra. But that doesn't mean you can't hire a developer (or even cursor) to change that. One can develop on replit and commit code to GitHub, which makes you free to use cursor (and also replit) for evolving and making it more robust. But that doesn't mean you'll throw it all out. It might just mean that your workflow switches to cursor and you work together with developers on the same repo. A second drawback I see is that replit and cursor are both in one single repo. As your feature set grows it makes it harder for the models to be fully aware of your context. Here again might you may hit a point where you want to hire someone to help you restructure and architect the code. It is not incompatible with the cursor idea i shared above. If I were in your place I would start by 1) dual development - replit and cursor - because it creates the foundation in GitHub for you to collab with a developer. You'll start using issues, actions etc. You'll gradually turn replit into one part of your dev cycle 2) start looking for a dev that could help you structure the code and architecture. All in all you don't need to ditch replit completely but you can grow further than it's vanilla usage