hugs

6 ms·

61.
by hugs 10mo ago
lots of people have already been posting examples of how they used vibium on linkedin. (code's only been available for a day or two, so we're just getting started!) we also have a new discord server for the project that we just sp
62.
by hugs 10mo ago
i partially addressed this in the "why vibium" section of the v1 announcement: https://github.com/VibiumDev/vibium/blob/main/docs/updates/2... but why a new thing vs extending seleniu
63.
by hugs 10mo ago
fully aware of the "blast radius" risk of using claude to do stuff. i'm doing all my vibium dev in a vm using UTM (and you should, too!). wonder if there are some network rules we can add. i did post a v2 roadmap on the githu
64.
by hugs 10mo ago
it's a good questionn! i partially addressed this in the "why vibium" section of the v1 announcement: https://github.com/VibiumDev/vibium/blob/main/docs/updates/2... to save a cl
65.
by hugs 10mo ago
what specific things were you looking for?
66.
Show HN: Vibium – Browser automation for AI and humans, by Selenium's creator(github.com)
443 points by hugs 10mo ago|124 comments
67.
by hugs 10mo ago
the tech industry is forever in denial that it is also actually a fashion industry.
68.
by hugs 10mo ago
feels like a new generation is learning what life is like when microsoft has a lot of power. (tl;dr: they try to use it.)
69.
by hugs 10mo ago
this is why i like (and vibe code in!) nim. it's python-ish enough, strongly typed, and creates fast, compiled binaries.
70.
by hugs 11mo ago
yup, vibium!
71.
by hugs 11mo ago
""Autonomously, an Antigravity Agent writes code for a new frontend feature, uses the terminal to launch localhost, and actuates the browser to test that the new feature works." very interesting times; i'm glad to see br
72.
by hugs 1y ago
probably, but i'm petty like that. i just really don't like async/await. i'm looking forward to eventually being punished for that opinion!
73.
by hugs 1y ago
same. i don't like async. i don't like having to prepend "await" to every line of code. instead, lately (in js), i've been playing more with worker threads, message passing, and the "atomics" api. i get th
74.
by hugs 1y ago
which specific functions/features of the browser control MCP do you lean on the most?
75.
by hugs 1y ago
just a theory, but as atproto matures, there are now other example projects using the protocol for other things besides "distributed twitter clone". for example, tangled was talked about yesterday. [1] and that probably came up be
76.
by hugs 1y ago
i'm very curious about tangled. i'm building a new thing (tl;dr: an e2e testing and monitoring service) and hope to add more distributed/decentralized functionality into its core. i had been leaning heavily towards using nost
77.
by hugs 1y ago
yes, "there are too many NIPs!" feels like a red herring. at the moment, as a developer, i feel comfortable picking and choosing which NIPs i might want to use for whatever i'm building. but i can also understand why that mig
78.
by hugs 1y ago
that is the best and worst aspect or nostr. it is a very interesting, semi-chaotic box of new toys to play with. reminds me of the early web. (the second best/worst aspect of nostr is key rotation.)
79.
by hugs 1y ago
yeah, that looks like a good base for a simplified remix. thanks!
80.
by hugs 1y ago
nostr can get plenty complicated, too, but nostr successfully tricked me into thinking it was simple enough to get started.
81.
by hugs 1y ago
i like seeing a bit of the raw, low-level protocol first. a few curl examples are perfect for understanding what’s really happening under the hood. once i get that, i'm happy to use a library to handle all the edge cases. but starting
82.
by hugs 1y ago
the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything
83.
by hugs 1y ago
thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user. i appreciate bsky's focus on user ux and community building and look forward to seeing more sharing of ideas between no
84.
by hugs 1y ago
i think it really is as simple as boiling it down into a doc that looks like nip-1 and saying, "this is the absolute minimum amount you need to understand and implement to start sending messages on an AT-based network." -- not fro
85.
by hugs 1y ago
from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"),
86.
by hugs 1y ago
"By 1965, it moved to Paramount Ranch in the Santa Monica Mountains" Fun personal fact: Paramount Ranch was also the site of my high school's home cross country course (Westlake High School). During my high school days, the r
87.
by hugs 1y ago
i've been working on an idea for a while to use those idle old phones for... distributed web and app testing. plug it in at night... wake up having made a few bucks. problem is getting anyone to really care, though. cloud hosting is ch
88.
by hugs 1y ago
one of us! one of us!
89.
by hugs 1y ago
would be awesome if they added nostr to the list, too.
90.
by hugs 1y ago
or we could just require postage. (HTTP status code 402) one potential solution: https://www.l402.org/

More ›