Lack of moderation combined with an offical-sounding domain name.
This would have to get the user to follow a link or call a phone number or something though. These are plausible. It's too bad the content-security-policy can't prevent following links.
Bluesky seems to use a lot of totally different domain names for each part of their infrastructure, maybe for this reason. e.g. this one is bsky.network
While they're nowhere close on volume, they're certainly beating microsoft in terms of the rate they're adding similar looking official URLs.
I mean, the way AT Proto is designed, moderation primarily happens on the app layer, not the protocol layer. So on an app like Bluesky, you can have a lot of moderation. But the protocol itself allows hosting arbitrary content in a distributed/decentralized way.
Blocking/allowlisting all JavaScript is the only way [1] to have a CSP fully contain an app (no exfiltration) [2] and with prefetch that might not be enough. The author is correct at the end to suggest using WebAssembly. (Also, it still has the issue of clicking links, which can be limited to certain domains or even data: by wrapping the untrusted code in an iframe and using child-src on the parent of the iframe)
You’ll need showdead enabled on your profile to see the whole thread, which speaks to the controversial nature of this issue on HN.
I agree that your mention of “encouraging accusatory behavior” is a point well-taken, and in the absence of evidence, such accusations themselves would likely run afoul of the Guidelines, but it’s worth noting that dang has said that LLM output itself is generally against the Guidelines, which could lead to a feedback loop of disinterested parties posting LLM content, only to be confronted with interested parties posting uninteresting takedowns of said LLM content and posters of it.
> There are lot of grey areas; for example, your GP comment wasn't just generated—it came with an annotation that you're a lawyer and thought it was sound. That's better than a completely pasted comment. But it was probably still on the wrong side of the line. We want comments that the commenters actually write, as part of curious human conversation.
This doesn't leave much room for AI non-slop:
> We want comments that the commenters actually write, as part of curious human conversation.
I think HN is trying to be good at being HN, not just to provide the most utility to its users in general. So those wanting something like HN if it started in 2030, may want to try and build a new site.
1. For whatever reason*, large swaths of LLM output copy-pasted is easily detectable.
2. If you're restrained, polite, with an accurate signal on this, you can indicate you see this, and won't get downvoted heavily. (ex. I'll post "my internal GPT detector went off, [1-2 sentence clipped version of why I think its wrong even if it wasn't GPT]")
3. People tend to downvote said content, as an ersatz vote.
In general, I don't think there needs to be a blanket ban against it, in the sense of I have absolutely no problem with LLM output per se, just lazy invocation of it, ex. large entry-level arguments that were copy-pasted.
i.e. I've used an LLM to sharpen my already-written rushed poor example, which didn't result in low-perplexity, standard-essay-formatted, content.
Additionally, IMHO it's not bad, per se, if someone invests in replying to an LLM. The fact they are replying indicates its an argument worth furthering with their own contribution.
* a strong indicator that a fundamental goal other than perplexity minimization may increase perceived quality
The reason is not strange or unknown. The text completion GPT-3 from 2020 often sounds more natural than 4. The reason is the post training processes. Models are more or less being trained to sound like that during RLHF. Stilted, robotic, like a good little assistant. Open AI, Anthropic have said as much. It's not a limitation of the loss function or even state of the art.
I don't know when I'll stop seeing surface-level opinions disguised as cold technological claims on this subject. I would have thought, by now, people doing that would wonder why the wide open lane hasn't been taken, at least once.
I don't understand what you're getting at here. No idea why you've put tweets from a random? person to make your point.
Yes these guys have all noted on the effects of post-training on the models.
"We want people to know that they’re interacting with a language model and not a person." This is literally a goal of post-training for all these companies. Even when they are training it to have a character, it mustn't sound like a person. It's no surprise they don't sound as natural as their base counterparts.
>You're wrong that its forced and immutable and a consequence of RLHF and the companies say its so.
I never said it was immutable. I said it was a consequence of post-training and it is. All the base models speak more naturally with much less effort.
>You're especially wrong that RLHF is undesirable
I don't understand what point you're trying to make here. I didn't say it was undesirable. I said it was heavily affecting how natural the models sounded.
>It's also nigh-trivial to get the completion model back
Try getting GPT-4o to write a story with villains that doesn't end with everyone singing Kumbaya and you'll see how much post-training affects the outputs of these models.
To me, the essence of online discussion boards is a mutual exchange of ideas, thoughts, and opinions via a shared context, all in service of a common goal of a meeting of minds. When one party uses LLMs, it undermines the unspoken agreement to post “authentic” content as opposed to “unauthentic” content. Authenticity in this context is not just a “nice to have,” but is part and parcel to the entire enterprise of participating in a shared experience and understanding via knowledge transfer and cross-cultural exchange.
I can see that you care enough to comment here in a “genuine” and good faith manner, as I recognize your username and your posting output as being in good faith. That being said, an increase in LLM-generated content on HN generally is likely to result in an associated increase in the number of bad actors using LLMs to advance their own ends. I don’t want to give bad actors any quarter, whether that be wiggle room or excuses about Guidelines or on-topic-ness, or any other justification for why self-proclaimed “good” actors think that using LLMs is okay when they do it, but not when bad actors do it, because doing so gives cover to bad actors to do so, as long as they don’t get caught.
> That being said, an increase in LLM-generated content on HN generally is likely to result in an associated increase in the number of bad actors using LLMs to advance their own ends.
This hit me like a ton of bricks, very true.
The older I get the more I understand the optimist in me rushes to volunteer good things that'll happen over the obvious bad.
This, in retrospect, will apply here too and is explanatory for some notably bad vibes I've had here the past year or two. (been here 15 years)
Additionally, IMHO it's not bad, per se, if someone invests in replying to an LLM. The fact they are replying indicates its an argument worth furthering with their own contribution
And once those floodgates are open, what exactly makes you think that they're not just also using an LLM to generate their "contribution"?
The odds of LLMs being used to produce content on HN is a number approaching 100%.
The odds of LLMs being trained / queried against data scraped from HN or HNSearch is even closer to 100%.
I know you don't like the "LLMs are allowed..." part, but they're here and they literally cannot be gotten rid of. However, this rule,
> As soon as possible, people should be made aware if they are interacting with, or their activity is being seen by, a LLM. Consider using line prefixes, channel topics, or channel entry messages.
Could be something that is strongly encouraged and helpful, and possibly the "good" LLM users would follow it.
These comments don't solve the annoyance of false assumptions on HN, because they often contain a false assumption of their own.
Google didn't have the same issue with confusion because of San Diego Colab that colab.sh will have if they keep their name and get popular. That's because San Diego Colab wasn't nearly as well known as Google Colab is now.
So I can say "Can we please stop" to your comment, and I'm sure you can find something with my comment and get in a loop of "can we please stop".
And then when this project explodes and becomes as well known as Electron is eclipsing Google Colab (I never heard of it until today) then your argument is invalid.
And you're right, we can keep getting into this loops, so lets nip it in the bud where it all begins and shocker, not tell people to change the name of their stuff because something else exists with a similar name but completely unrelated.
I dunno, MongoDB is as if it's gone, due to a license change in 2018. So asking if redis should be thought of the same as MongoDB is a legitimate question.
Mongodb is gone; everyone stopped using it. The publicly traded company behind it with thousands of employees and over a billion in revenue is a figment of your imagination.
It's kind of like how Java still exists but doesn't commonly run in browsers in the form of a Java Applet. It exists behind the scenes and I'm sure many who used to use it now use it indirectly.
It's sort of as if it's gone. TFA is about what I no longer recognize as what I used to mean when I talked about redis. Since the license change the project with the trademark no longer fits that concept. Valkey does. I'm not sure where I ca find something that fit my old context of MongoDB.
If this is indeed like Plaid, a simple clause in the README would put a lot of people at ease (I looked carefully for this before making my comment): This Unofficial API was built with the express written consent of Venmo (or whatever their LLC is called).
It’s an easy thing to add to the README if it’s true. But if it’s not, that’s a problem.
Mind providing a link so I can validate this? Plaid might have API providers' permission now, but did they at the start? I forgot to mention that I was talking about when Plaid first started.
Plaid use screen scraping which is why it breaks all the time. In terms of reverse engineering undocumented but official APIs, you’re thinking of their competitor Teller.
I was under the impression that they've built up much warmer relationships on the financial account side and correspondingly have more reliable integrations than they used to.
I've personally noticed it tends to break a lot less than it used to.
For the misleading part, I probably should have said confusing because I don't think you intended that, I mean that instead of introducing your caching layer you make it about S3, where the Object Storage provider seems totally interchangeable. Though it seems to work for a lot of your audience, from what I can tell from other comments here.
As for Express One Zone providing consistency, it would make more groups of operations consistent, provided that the clients could access the endpoints with low latency. It wouldn't be a guarantee but it would be practical for some applications. It depends on what the problem is - for instance, do you want someone to never see noticeably stale data? I can definitely see that happening with Express One Zone if it's as described.
Yes, I think this is something that I’m actually struggling with. What’s the most exciting part for users? Is it the fact that we’re building a super fast file system or is it that we have this synchronization to S3? Ultimately, there just isn’t space for it all — but I appreciate the feedback.
I think they both go together. It might take about 10 minutes to give a good high level explanation of it, including how the S3 syncing works - that the S3 lags slightly behind the caching layer for reads, and that you can still write to S3. 2-way sync. I imagine that S3 would be treated sort of like another client if updates came from S3 and the clients at the same time. It would probably be not so great to write to S3 if you aren't writing to somewhere that's being actively edited, but if you want to write to a dormant area of S3 directly, that's fine.
The criticism wasn’t only about how limited the DSL was — it was about how some of the design choices are repeating patterns which are very common sources of security defects. HTML and SQL are DSLs themselves and have non-trivial security contexts.
That isn't the sense I get from the example. It shows an entire user-facing web application being written in this language, with every indication that the author thinks this is an appropriate use case.
Gliimly is a very high-level modeling language. It's about solving problems by modeling the solution and connecting the components to create high-performance, low-footprint executables; and not about managing memory, manipulating bits and bytes or writing complex code.
Syntax matters
Syntax of a language matters, not just for writing code now, but for someone else reading it years later. Gliimly language is designed to be intuitive, easy and rapid in use on both ends, and to be close to the way humans are wired, rather than machines.
Language
Gliimly programming language is memory-safe, meaning it will prevent you from accidentally overwriting memory or freeing it when it shouldn't be. Gliimly's memory-handling is not limited to just memory safety; it also includes automatic freeing of memory at the end of a request, preventing memory leaks which can be fatal to long running processes. Similarly, files open with file-handling statements are automatically closed at the end of each request, serving the same purpose.
Types
Gliimly is a strongly-typed language, with only three primitive types (numbers, strings and booleans) and a number of structured types (message, split-string, array, index, index-cursor, fifo, lifo, list, file and service). Gliimly is a declarative language, with a few lines of code implementing large functionalities. Gliimly is also very simple - it does not even have expressions! That's because it's designed to achieve application goals with less coding.
Gliimly statements are designed for safety, ease of use, and ability to write stable code. Most statements typically perform common complex tasks with options to easily customize them; such options are compile-time whenever possible, increasing run-time performance.
It's interesting, something to look into. It's not a general purpose language, true, and I think that's a good thing. General purpose languages are too broad for the topic of web services. It's like when SQL came out long ago to make database programming specialized. I think we need something like that for web services, and Gliimly may be a good step forward.
Yeah I meant that in a good way. You can build powerful stuff with a DSL that doesn't include the normal imperative programming constructs that most general purpose programming languages, but also some specialized programming languages like bash, include. jq is a nice alternative to python for sifting through JSON for many things.
I think glimly is an interesting project but I wonder why they don't use something like mustache ({{ param1 }} for escaped and {{{ param2 }}} for unescaped) instead of p_web
Worse case, just drop to hexadecimal.
reply