tbiehn

Nice (and MIT Licensed!) - I'll give this a shot.

Another thing these types of tools bring is multiplayer support. Which I found my distributed teams really benefiting from over time.

This project (and others like it) are graphviz wrappers - they do some really cool stuff to emit styled .dot files that look better than writing and rendering raw gv.#

Allowing specification in Python offers very little advantage - in theory you think, hey, I've got hi-lighting, autocompletion, and so on from an IDE. It'll play nice in VCS. Maybe I can interrogate orchestration layers and so on to produce dynamic views.

In practice diagrams are produced by folks who might not want to use or learn python [or golang, their other implementation]. Instead a lean purpose-build DSL, maybe even an extension of graphviz dot, is easier and more portable for some audiences to pick up. Secondly, we can't JUST graft a DSL front-end onto these tools because the styled components are baked into the project.

My personal experience with layout engines is that they work OK for very small architecture diagrams, but become ugly or inelegant at useful scales.

I (and the teams I've worked with) settle on draw.io, either the desktop app, or committed as part of confluence, as the best way to describe intent/design - and rendering graphviz with a style up top for anything dynamic.

Would welcome seeing a true extension to the dot language that can unlock reasoning engines (like to do threat modeling) and render-time styling.

Semgrep is another great option to get value out of static analysis checks against both the language and a few common frameworks. It remains a popular choice for security folks writing static detection rules (and contributing them to the commons).

You can check the open rules here; https://github.com/semgrep/semgrep-rules/tree/develop/go

Interesting idea - do you handle ‘dead keys’ as well? Let’s say you optimistically re-fetch a few times, but no client re-requests?

Just imagine if we didn’t use heuristics to fix arbitrary inputs and instead we used some sort of learning algorithm that was trained on producing valid looking json - then all we’d need to do is add a prompt and start with some random noise… :P

Not the fort-knox implementation it claims on the tin.

'LocalSend uses a secure communication protocol that allows devices to communicate with each other using a REST API. All data is sent securely over HTTPS, and the TLS/SSL certificate is generated on the fly on each device, ensuring maximum security.'

How do they achieve maximum security while generating X.509 certs on device?

Let's look; 'https://github.com/localsend/protocol#2-fingerprint'

'When encryption is on (HTTPS), then the fingerprint is the SHA-256 hash of the certificate'

Confusingly there is a HTTP non encrypted mode, and the docs claim the fingerprint only used to avoid discovery collisions.

Out-of-band [visual comparison / QR code scanning step] sharing of fingerprints COULD be acceptable to prevent 'man in the middle' attacks, however the documentation doesn't seem to indicate that this detail is surfaced or shared with the user. The discovery protocols look 'hella sus', but most local media sharing and discovery is.

Reminds me of https://tinygo.org/ - a project that brings Golang to embedded devices, browser (wasm) contexts. Do you converge or diverge from that project?

I’m chatting with a founder who started building a moderation pipeline with gpt-4 w/ embeddings to save credits & time. Seems like something that will become ubiquitous.

This article shines a light on exactly why LLMs /arent/ just autocomplete with context. There’s real computation going on in there. https://arstechnica.com/science/2023/07/a-jargon-free-explan...

A tip for your context window problem: prefer ‘editing’ a previous message to add whatever clarification is required - rather than having a ‘chat.’ Definitely helps keep it on the rails.

Yet another DNS file delivery thing - wrote a few years ago to get files into restrictive networks and results out: https://dualuse.io/blog/dnspump/

Another factor; so many programs today either require or… at least try a network connection before they actually DO anything.

I keep plugging my own… yet another API invoker - with parallel queries, templates, and config files written in Golang; https://github.com/tbiehn/thoughtloom Has some interesting examples, but I expect the population of users to be constrained to the 5 of us that enjoy CLI, jq, and writing bash scripts.

I wonder if the author had ever tried milkdrop before? Seems like the same type of thing. https://en.m.wikipedia.org/wiki/MilkDrop

The whole thing actually goes back to smoking weed. The ‘no mouse ethos’ goes at least as far back as the ratpoison window manager and this historic post: https://www.nongnu.org/ratpoison/inspiration.html Tiling window managers, living in terminals, vi, that Firefox with vi keybinding - all part of this THC cult. I recall some other ideologically foundational work where the author talked about being able to work one handed with this type of setup, in this case I think performance is taking a back seat to joint-smoking ergonomics.

I don't think 'young traders' get news from bloomberg articles quoting dudes in totally sick ascots. It's almost self-parody.

You, like me, might be looking for benchmarks; https://www.phoronix.com/scan.php?page=article&item=radeon-g...

So if a host supports SNI you send it 400+mil requests? C'mon, dish.

Interesting, some results out of Shodan were surprising - this might be the reason. How do you pick what domains to try?

It turns out that if you have a targeted domain you have a good chance of finding it in one of the popular cloud hosting ranges. Masscan + curryfinger work well together. Alexatop + masscan + curryfinger makes an interesting dataset.

This is a neat approach - but the current implementations adjacent-line tab-stopping only works if you put block opens on separate lines.

This is exactly my point - the available controls are not sufficient (plus immature). Providing a control that lets you create trusted client code lets you (comprehensively) cover the risk of code introduced 'after build time'. This would be obviously difficult to deploy - but it isn't without precedent, most clients (that aren't web) are already protected by signatures at build time, and orgs where that really matters (Signal, GPG, etc) get to pursue signing on air-gapped computers, with ceremonies and deterministic build processes. Preventing the implanting of client code has been deemed so important that even when updates go out over TLS, their signatures are double-checked by the recipient. I do not see how our use of the web-browser as a client becomes more trivial over time, it is clear that eventually the exposed capabilities, and desired use-cases, will eventually mandate assemblies verifiable in this manner.