yesterday at 7:46 PM
> No channel modes and no channel operators, which is a decision rather than a gap: a global channel is owned by nobody, so there is nobody to be an operator of it. Blocking is per person and per instance instead
That's completely unworkable. Lets say I create #some_minority, and people from many different servers join. Some shithead comes and starts screaming slurs at us. Now the admin for every server must block that person. Multiply that by every channel, and every admin is responsible for moderating the entire ecosystem. The only way they can do this is with shared blocklists, which have been a nightmare on mastodon.
yesterday at 9:09 PM
If this is really distributed, then off the top of my head I imagine you could possibly make some sort of reputation-based filter list wherein trusted admins can subscrbe to each other's filter lists such that when one admin blocks are user, it quickly propagates to other admins' lists. Somewhat similar to how email domain spam block lists work.
today at 12:22 AM
That would quickly get abused and cartels would form over the larger servers about who has access and where.
today at 2:17 AM
Yes, but the point being "trusted". If the community decides a particular admin/group/server is unjustly handing out bans, then they could unsubscribe from that list.
today at 2:18 AM
[delayed]
yesterday at 8:29 PM
[seemingly negative thing] which is a decision (after hindsight), rather than a gap [scope creep]
yesterday at 8:44 PM
Ownership of namespaces is such a hard problem, our society has had to form global organizations and some of our most secure distributed systems to make it happen.
Working in the p2p space, scalable namespace ownership that doesn't get instantly ruined by perverse incentives is the holy grail. I don't think it is actually tractable in any "central authority free" system. Don't get me started on blockchains that tether names to the most perverse systems available and call it victory.
yesterday at 10:52 PM
Given that this system already uses DNS for namespacing of user identifiers (via instances), it seems like it could use DNS for namespacing of channels too
yesterday at 8:12 PM
> which have been a nightmare on mastodon
Why?
yesterday at 9:57 PM
I get the impression that every attempt to make block lists ends up getting used to target people an admin of the block list doesn't like. I think the root of it is that the admins consuming the blocklist don't want to have to spend time on moderation and are remote from communities where the blocklist is happening. Also the scope of the blocklist is the instance. Compare that to community internal moderation (e.g. channel mods), where someone close to the community is invested in the health of the community and the scope of the block is the relevant community.
yesterday at 11:11 PM
If you tweet something controversial once and the wrong person sees it, they can automatically tag you as a nazi across half the fediverse
yesterday at 8:31 PM
gestures broadly is going to be one of the common answers from anyone trying to ward off spam
yesterday at 1:22 PM
How do you plan to handle bad actors creating biblical amounts of servers dynamically and then spamming at line rate from all of those servers?
yesterday at 11:12 PM
Why would they need to "create servers" instead of just throwing UDP packets at you like a normal DDOS?
yesterday at 11:23 PM
Because throwing UDP packets requires a bandwidth advantage (aside from reflection attacks), whereas application-layer attacks can impose an outsized cost on the victim.
yesterday at 11:47 PM
But you said line rate - that's a simple bandwidth exhaustion.
yesterday at 11:49 PM
Line rate of sender != line rate of receiver (I am also not GP).
yesterday at 3:24 PM
That sounds pretty load-bearing.
yesterday at 4:06 PM
Actually itâs a footgun gate
yesterday at 8:37 PM
An honest gap
yesterday at 3:29 PM
And then, all galaxies move away from us.
yesterday at 1:24 PM
This is why we can no longer have nice things...
yesterday at 9:43 PM
Online communities are meant to be pharmed..
yesterday at 12:24 PM
So rooms are "global" between whatever hosts your host happens to know about? So it's one giant netsplit party forever and only your server admin can ban someone?
yesterday at 12:35 PM
Bans are per server (for what I have seeing). Federated rooms continue to exist if a server drops off, as no server "owns" them.
yesterday at 7:27 PM
Relearning the lessons from the old days, I see. This situation is what created the Eris-Free Network.
yesterday at 1:00 PM
> Federated rooms continue to exist if a server drops off
That doesn't answer the question.
How are you resolving things like... user name collisions when the servers reconnect?
yesterday at 1:18 PM
I am not the owner of the project, I just use it. Federated rooms have no owners, there will be no collisions (they would simply merge). Nicks are tied to their own servers, and hence unique and will not collide.
yesterday at 1:59 PM
This has been an issue for as long as IRC itself has existed. There are solutions to resolve such "netsplits" and "netjoins", but they all rely on the servers in the network being trusted and not malicious.
With Parley, where anyone can bring their own instance, and they are not guaranteed to not to be malicious, that could be an interesting issue to solve.
yesterday at 3:20 PM
CAP theorem suggests it is not solvable.
yesterday at 11:13 PM
This like most federated systems is AP. Cut a federation link and you create two or more different state views.
yesterday at 10:30 AM
Parley is a chat network with no centre.
Every person (or team) runs a small instance for their own domain. Instances find each other through DNS and well-known identity documents, exchange signed messages over HTTPS, and present the whole federated network to ordinary IRC clients such as Lurker, Mango, mIRC, WeeChat, Textual, etc., without the need of any plugins.
yesterday at 12:09 PM
This is an AI-generated summary of TFA?
yesterday at 12:49 PM
It's a copy paste of the readme intro. Don't know why it's left as a comment here
yesterday at 1:25 PM
Hacker News marketing skills tell people to leave a context comment on Hacker News. Don't complain about it too much, that is our way of figuring out who is lazy in an obvious way!
yesterday at 1:44 PM
When someone makes a submission, the text field becomes a comment when the URL field is not empty. (but sometimes not?) It's a poorly designed form that should be redone.
yesterday at 10:36 AM
can any layman user simply use it without running their own instance?
yesterday at 10:38 AM
Yes, you will need to know someone running an instance to create an account for you.
yesterday at 10:58 AM
So... no? :)
yesterday at 11:40 AM
Presumably if the protocol becomes popular you will have public instances that anyone* can sign up to, the same way other federated services work now.
(It's approximately as hard for a layman user to sign up to a Mastodon instance as it is to sign up for X. The fact that most layman users don't do that is a separate issue.)
yesterday at 11:06 AM
Yes, you can try it without running your own instance. You will need to use someone else's instance.
yesterday at 11:00 AM
If you (top and child commentator) want to try without running your own, please send me an email: david dot collantes at gmail dot com.
yesterday at 7:37 PM
Is anyone leveraging IRC/XMPP/etc for agents or A2A communication? It seems like a natural fit; all the "human agents communicating" abstractions and underlying technology pieces are in place and mature, as are methods for dealing with unruly actors.
I've wondered why I haven't seen this everywhere.
today at 12:10 AM
I prototyped it, and - in my experience - it didn't work as well as having them just communicate by spawning processes.
yesterday at 7:42 PM
Oh my pi does it, not sure if thatâs something from upstream or just a fork feature but from my experience it seems to work well
yesterday at 9:04 PM
Haha so this project speaks IRC, no less :) This is surely relevant then: https://www.mirc.com/split.html
yesterday at 9:48 PM
Internet drama was so much better back then.
today at 12:33 AM
This is the path forward for the Internet. Social media of near future will have to be fully decentralized.
The levels of financial censorship had reached the point where third party contents hosted by any centralized entity, be it a publicly traded company like Twitter or just a volunteer individual like on a Mastodon instance, is basically unviable. In the latest case with Clip Studio asset store incident that happened just last week, completely benign materials such as simple drawing reference materials of abstract men playing soccer/football and kimono brush patterns for a snake were flagged and deleted as "pornographic or violent". There is nothing SFW at this point; the thresholds for censorship just keeps going up and it maintains constant pressure against all expressions however innocent - if everyone follows their rules, their rules must change to make up violators. Rules and standards also significantly diverge between places and photos of people can be literally illegal by standards of somewhere or someone deeply disconnected, at this time.
While the absurdity of that is fought in the field of politics or whatever ways that works, social media has to switch to distributed online/offline mesh networks that can still create the viral behaviors, one which nobody is forced to host or share what they personally consider illegal or risky, unlike raw P2P system that could be labeled as itself illegal and/or its use inherently malicious, as how Winny and later Bittorrent, to some extent, was made out to be. It has to be something like a distributed hybrid of Google+, Discord, IRC and Reddit, but with minimum centralized infrastructure that can be plausibly operated as not primarily intended for blatantly illegal use cases that would justify helicopter raids and flashbangs into living rooms(which European counter terrorism units have done in the past; they've been that much deranged for years).
IMO the challenge is in making it trivially selfhostable. At least the server part has to be usable by someone who could barely install a GPU, and ideally the phone app should work as a server for local friends for completely legitimate fun purposes. Then it also has to be able to handle what comes down or goes up to the global net at the same time. How it could be done behind heavily NAT'd current Internet can be tricky.
yesterday at 12:27 PM
Thereâs a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.
In this case, this is basically a poorly specified implementation of half of XMPP. Of course, I half expect the LLM would have mentioned that at some point, but the repository does not.
yesterday at 1:22 PM
Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.
I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
yesterday at 3:55 PM
IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.
I briefly entertained building a modern chat experience on top of IRC when I came to this realization.
yesterday at 5:02 PM
Slack was originally a side project built by a game dev company as a set of scripts on top of IRC. https://en.wikipedia.org/wiki/Slack_(software)#History
yesterday at 6:09 PM
IRC really is good. It's reliable too, but it really fell behind the times and never pushed forward with additions to the spec and such. When the clients and libraries tapered off too it just felt like it froze.
yesterday at 5:39 PM
IRCv3 aimed to do this, with mixed results.
yesterday at 2:19 PM
>Unfortunately XMPP is an absolutely terrible protocol
Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.
today at 1:36 AM
I will say that the middle layer is not great. I have an XMPP bot and the "interaction with the network" stuff really is ugly and unfun.
I think the protocol itself is... I mean it's fine, I guess? Protocols are tricky because a lot of stuff is bolted on and it's not really super stateless as a protocol. But like all the Python XMPP client libs (for example) are all real janky.
The protocol is complex enough to where the "simple and easy" client libs require way more up front design.
yesterday at 2:21 PM
Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all
yesterday at 2:29 PM
I don't have that many problems with XML myself, but XMPP is weird even in XML land, because it tries to do XML all the way.
For instance, it works as a constant, uninterrupted stream. You never close the document until the disconnection. Which means you absolutely have to parse it with a stream parser.
It could have been something sensible, like a document per message: "Here's 300 characters of XML document: <xml>....". But nope.
And what's up with this? https://xmpp.org/extensions/xep-0394.html
yesterday at 3:04 PM
OMG, that XEP is extremely and unnecessarily complex. Just do, I don't know, markdown.
That made me remember IBM JSONx... https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=2...
yesterday at 3:29 PM
Whatâs so complex about it? From what I gather (after skimming the document just now), you attach an extra element to a message which says how to style which parts of the message, from codepoint n to codepoint m, essentially. At least conceptually, that seems really simple and straightforward.
Are there more elegant or natural ways to do it? Probably. But when you say âextremely complexâ, saying âcodepoints 7 to 15 should be boldâ is not what comes to my mind.
yesterday at 5:11 PM
Things I don't like:
* It's not standard. You can't plug in some normal formatting library there and be done with it.
* You'll probably end up having to write conversions back and forth.
* It's fragile -- if anything gets misaligned it'll break
* It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or <b>this</b>, but practically nothing is set up to accommodate this format.
* It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.
Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.
If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.
yesterday at 6:13 PM
None of this seems particularly different from doing <i>spans</i> inline (what if you forget to close one? or they overlap?), but it has a major benefit of being very backwards compatible, supporting future variants in parallel for gradual migration, and doesn't require any changes to search tools. And separating markup instructions from content is generally a very good idea.
And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back.
And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.
yesterday at 11:22 PM
Since the whole thing takes place in XML land I think there's no excuse for making clients implement markdown parsers as well. Bold should be <b> or <bold> or at least <font style="bold"> or <span style="font-weight:bold">. Embedding markdown in XML is silly.
yesterday at 4:14 PM
The following example (from the spec) seems quite fragile:
<message>
<body>This XEP supports many things:
* inline markup
* code blocks
* lists
* and possibly more!</body>
<markup xmlns="urn:xmpp:markup:0">
<list start="31" end="89" ordered="false">
<li start="31"/>
<li start="47"/>
<li start="61"/>
<li start="69"/>
</list>
</markup>
</message>yesterday at 11:20 PM
You're in XML land. Just do XHTML or whatever subset you think is useful for IM.
yesterday at 4:14 PM
yesterday at 7:53 PM
Is there a better standard available? As far as I know, XMPP is a real standard. If it's outdated, is there a better one?
yesterday at 3:12 PM
Identities. Creating an identity in XMPP is an absolute mess and requires domains along with approvals. At least in IRC this isn't complicated.
My own preference goes to NOSTR, just a set of public/private keys as identity and nothing else needed.
yesterday at 6:52 PM
Or ANproto https://anproto.com/ without the nostr baggage, what little there is.
yesterday at 9:01 PM
There is zero baggage on NOSTR regarding identities. An npub became the non-ambiguous way to reference anyone regardless of where they are writing from.
Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
yesterday at 11:23 PM
Doesn't nostr also forego routing metadata?
yesterday at 2:25 PM
Other people provided some info:
https://news.ycombinator.com/item?id=9772968
https://news.ycombinator.com/item?id=31133082 (article and discussion)
But TL;DR:
* It's hard to even parse, XMPP uses an uninterrupted XML stream. * The contents are often baroque and complex * Standards are a mess, and stuff that should be in core isn't * Data loss is possible * Protocol wasn't made for mobile devices * Multiple devices are terribly supported * Data loss is possible
From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
yesterday at 2:27 PM
Regarding the part part: https://www.process-one.net/blog/stop-telling-us-xmpp-should...
yesterday at 2:46 PM
> We hear this too often: âXMPP uses XML. It should use JSONâitâs more modern.â
I can't take this write-up seriously if it starts like that. I still read the whole thing though and I couldn't find any solid argument as to why someone would prefer XML to JSON for XMPP.
> This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. Thatâs why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTXâa lightweight parser built specifically for XMPPâs streaming modelârather than the browserâs DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.
That to me, is an argument for using JSON, not XML. XML is strong when you have elements referencing other elements in your document structure or DOCTYPE for grammar defs. I might be missing something but I don't get how streaming XML is to be preferred over JSON for XMPP.
yesterday at 5:58 PM
If it was actually using XML as a markup language then that would be a reason to stick with it. But XML seems to be complicating things much more than it simplifies.
>> XML remains the best format for representing treesâdeep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. Thatâs where XML shines.
Anything reasonable you'd be doing with messaging protocol is pretty flat.
yesterday at 11:28 PM
It should be JSON with embedded XML for message text markup, playing to each ones strengths... not combining two sets of weaknesses by framing in XML and then using Markdown to format the messages.
yesterday at 2:52 PM
yesterday at 2:30 PM
What part part, sorry?
yesterday at 4:25 PM
That there are issues with feature differences is a problem with the protocol.
Good protocols are opinionated and make concrete choices.
Extensibility typically leads to compatibility issues like the ones you are describing.
yesterday at 2:21 PM
I once implemented the presence and basic messaging functionality of XMPP for a web site, using a braindead bridge (that I also wrote; so, the meaningful logic lived in the browser).
Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.
What's wrong with it?
yesterday at 4:00 PM
These days complicated and/or complex == hard == bad.
yesterday at 4:23 PM
Which is understandable when messaging shouldnât be a hard problem to solve.
yesterday at 2:40 PM
> I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.
yesterday at 3:30 PM
This is what boggles my mind. We're talking decades of arguments and discussions, dozens of different ways to do it, with dozens of tradeoffs that you could start listing with 20 seconds of thought, and still people just pop in like "why isn't it simple??" as if that's some award winning insight.
Come on, try! Start listing some of the core features of the different protocols/clients and answer your own question as to why it isn't simple! Presence. Chat history while offline. Threading. Mobile devices. Intermittent/mobile/cellular/wifi/CGNAT connectivity. Multiple clients on the same identity and presence. Identity establishing and confirming. Encryption. End-to-end encryption. Backing up and restoring chats, encrypted chats, group chats. Federation. Friends/groups/permissions/trust boundaries. Markup, markdown, formatting, images, emoji, unicode, code blocks. Audio, video, broadcast, multicast. Discovery. Extensibility. Federation. Store-and-forward.
> "We've been sending text over the Internet from the moment the Internet went online"
And IRC has RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194 and it does almost none of those things.
And you can still use IRC. But IRC is not good. At this point it's either wilfull ignorance of what people use computers for, or it's indistinguishable from deliberate trolling.
yesterday at 3:46 PM
Threading? God, I hate threads in a live chat. Is it never not awkward to use? Slack is the example I'm thinking of, though I'm sure it's shit everywhere else too. In Slack, rather than display the one threaded reply just below (maybe indented), it makes me go to another window, but then someone else is replying non-threaded, so I have to bounce back and forth for the next 10 minutes.
yesterday at 8:49 PM
As an anecdotal counter-point, I love threads in a live chat. When used correctly, it means when my idiot friends start having a heated discussion about some random topic while I'm at work, I get one 'ding' from my phone and then never again until I start interacting or they @ me. As opposed to the 427 new notifications I get on my phone about whether Golden Eye was better than Mario Kart 64.
Ultimately the tech is only as good as the humans that use it. If you're chatting with folks that can't understand the difference between a thread or not, that's a meat-bag issue and not anything an RFC can fix.
yesterday at 5:37 PM
I completely agree. Threads in Slack should be a great way to make conversations easy to navigate but damn did they fsck up ever part of the UX:
- opening threads in a new window is in some hard to find and hard to remember location
- threads canât be inlined (like youâve described). I actually like how theyâre in a pane to the right but sometimes that causes issues (as youâve described). Sometimes itâs just that the view is too narrow.
- thereâs no way to shift non-threaded comments into the thread. Iâve lost count of the number of times conversations have happened over multiple threads and/or non-threaded replies.
The way they implemented it is a complete clusterfuck.
yesterday at 4:07 PM
I have half-wondered many times whether it would be possible/practical to build a chat system on top of MQTT or similar. Chat seems like mostly a pub/sub problem from where I sit.
today at 12:22 AM
Congrats, you just described XMPP
yesterday at 2:11 PM
Why is it terrible?
yesterday at 12:58 PM
That is currently still the differentiator between people producing code and shipping something and people who care and actually have years of experience shipping. At the current state how well you steer the LLM and which questions you ask still matters, maybe in the future "build me an app" will give amazing results, but right now you still need to know what you are doing.
In this case, it's just a waste of tokens as something not very unique was generated that doesn't have a real use case, or solves anyone's problem. As with many AI generated projects, I'm willing to bet that OP themselves will not using it any more in a month.
yesterday at 1:23 PM
You guys are way too critical and about the wrong things. "Waste of tokens"? Perhaps the author know of the tradeoffs and just wanted to build something.
How you went from seeing somebody's post to deciding they don't care is a pretty big jump, one that isn't warranted. This kind of post seems like the old but now more elaborated form of hating on something that you don't even know what it is.
It just isn't fair to the work that has been put in.
yesterday at 2:21 PM
I agree. This is one thing that's gotten me about the new wave of poo-pooing projects made since coding agents have gotten big. Five years ago it was 'just build something!'. I understand the market is more saturated now so building something isn't as valuable as it used to be, but it still shouldn't be treated as a negative. I don't know anything about the creator's background, but even if this project is ultimately redundant and unnecessary, it's still pretty cool that they built something.
yesterday at 3:47 PM
Because this isn't an example of "just build something" it's an example of "just order something from grubhub"
yesterday at 2:03 PM
If telling people âbuild me an appâ with no knowledge of technology worked, project managers would be good at their jobs already
yesterday at 1:05 PM
or maybe they know about XMPP and prefer IRC. I have always wanted to build one of these on top of IRC. I grew up on IRC and sometimes just the nostalgia of familiar tech is what drives us to build towards it not how good it is.
yesterday at 1:22 PM
Thatâs where weâd expect a mention in the README to play a part.
yesterday at 12:55 PM
I've done this a few times. If I had to gesture at the root cause I'd say: LLMs lack curiosity and are trained to complete assignments, not to question their validity, so both the research phase and the questioning of intent tend to get short shrift prior to building anything.
yesterday at 1:32 PM
I'm not sure I agree. Seems to me to depend a lot on how one interacts with an LLM.
If you tell it to "build me an application X to do Y using programming language Z", it will comply.
If you interactively ask "I need X, can you suggest some options? use an existing product ? or build something using a library ? or build entirely myself ? can you suggest alternatives with pro's and con's ? Anything I should think of before deciding ?" then you will get an entirely different answer.
Maybe we need additional modes, aside from thinking mode, agentic mode etc. we need e.g. "sparring mode" ? or does such a thing already exist ?
yesterday at 2:06 PM
Matt Pocock's skills library includes "grill-me" which is precisely this. It's excellent.
yesterday at 1:30 PM
yesterday at 1:20 PM
Agreed, you have to ask them to look for prior work. But then they will do a good job finding it in most cases. I think itâs partly their universal tunnel vision and partly sycophancy.
yesterday at 2:31 PM
Specifically it's important to ask for more than a few examples.
yesterday at 3:18 PM
> I half expect the LLM would have mentioned that at some point, but the repository does not.
The repository does not even mention this software is LLM-generated.
I wonder when/if the collective realization will land that LLM's failure to retain provenance during training means the code it generates exists in an indeterminate state of public domain / IP trap.
yesterday at 11:32 PM
"retaining provenance" isn't a real thing. Courts have ruled and keep ruling that a model is not a derivative work of its training data.
yesterday at 6:35 PM
The AGENTS.md file in the repo with its contents is a pretty clear giveaway though.
yesterday at 2:09 PM
LLMs could be asked to research extra projects.
It's valid that someone just wanted to build something like this for their own purposes.
yesterday at 2:13 PM
But it's not just for their own purposes. They shared it with the public which means they will get feedback, good and bad. No one forced them to post to HN.
yesterday at 2:28 PM
Agreed, and the vast majority of personal projects that are released as open source don't get attention, traction, or contributions.
In this case, someone shipped something that works for their use case, which is a great deal more than talking.
yesterday at 2:34 PM
Sure but it will still be scrutinized and compared. I don't see the issue.
yesterday at 3:16 PM
Maybe some people just ship and post and don't look back in terms of scrutiny / comparing.
There's lots of approaches out there that say if you don't ship something embarrassing, it's too late.
I think this is the main point I was trying to make and our exchange helped me bring it forward, thanks.
yesterday at 3:41 PM
âThereâs a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.â
Thatâs because itâs a paradigm shift, not meant to be planned or organized by humans. The prior paradigm was that there were subject-matter experts who were human. The new paradigm is that the only author of all code is to be a machine. This new paradigm requires removing all prior authors (who happen to be human), and removing them simply requires overcrowding their output such that itâs not locatable or trustworthy.
Sit back, grab some popcorn.
yesterday at 3:39 PM
Ya, ive stopped interacting with all new projects, the amount of slop written by people who have no business remotely putting something out there for others to use is untenable.
The system has broken under the noise.
yesterday at 1:20 PM
XMPP is massively bloated protocol that is badly managed for last 2 decades
yesterday at 2:12 PM
And what are you suggesting as a non-bloated and better managed alternative? :)
yesterday at 2:54 PM
Maybe Matrix?
yesterday at 11:34 PM
Matrix turns every chatroom into a blockchain with a distributed consensus algorithm.
IRC (real IRC) solves this by not solving it, and accepting that message order can differ between servers. If two operators kick each other on two different servers at the same time, usually both get kicked - the command is validated on the origin server and the rest of the network takes it as gospel, even if it doesn't make much sense in their own local state.
yesterday at 5:34 PM
Synapse basically brought my vps to its knees with like 5 users. I would not call it light.
yesterday at 3:34 PM
Is Matrix really non-bloated? My impression has been that it works more reliably, but isnât considered lean at all.
yesterday at 3:59 PM
yesterday at 11:41 AM
Interesting. Why not use an open link network? These will result in around the same state. Spam _will_ be an issue here, in general. And with a different backend you're going to struggle to use preexisting tooling to handle it.
Using & channels is fun, I'd be interested to see how many bots and clients fall over dead when faced with that particular bit of IRC history.
yesterday at 12:13 PM
IRC linking is a mess, in part due to the spanning tree requirement. Also the server to server protocol in the RFC is spoken by zero servers so you have to pick which unofficial protocol you like best. May as well invent your own that actually fits your use case.
yesterday at 1:28 PM
Except that now there's yet another standard, which nothing but this thing speaks. TS6 is very well used at the moment as everything in the Charybdis line speaks it, etc.
yesterday at 9:52 PM
This one works differently, which is enough reason to make it different.
yesterday at 4:56 PM
I'm searching for a simple, self-hosted chat system that allows me to host unlimited bots and send messages (with notifications) to my iPhone easily.
I currently have an XMPP server running, which is fine, I guess. I've looked into chatMail. I have considered hosting an IRC server.
At this point, I'm considering just setting up my own NTFY server and writing a chat client for it.
Does anyone have any ideas for what the lightest weight, simplest solution might be?
yesterday at 5:05 PM
Curious, why the interest in building your own ntfy client (instead of using the one already built/available)?
By the way, for years now, i have used a little python (cli) app to send messages into a private matrix room. This room has 2 people in it: me and a bot. (The bot is simply the matrix account that sends the messages.) I went this route because i did not want to install another app - such as ntfy - on my mobile simply to receive server notifications, etc. And, since i had ben on matrix already chatting with friends, it happened to be a low-effort approach. To clarify, i am no longer self-hosting my own synapse home server...so i'm simply piggybacking on the matrix.org one...but that has helped at least unify my notifications and comms to a good degree.
Now, if you were to aske me to implement my "notifications system" via a different approach, funny enough, i would gauge between XMPP and ntfy to see which is lighterweight....because i believe them to both be quite light on the need for resources. I don't know which is lighter (sorry, i know i'm not answering your question). however, i *think* the ntfy server is less hasle....Only because xmpp takes a little more work to setup...at least that was my experience a couple of years ago. I cast no shade on either xmpp nor ntfy - because to me boh are awesome...i' m merely saying that resources needs aside, i wonder if ntfy might need less time from YOU.
yesterday at 6:45 PM
I'd build my own NTFY client to enable two-way chat. It's not something I'm seriously considering, because it's obviously a bad idea, but that's about where I am.
yesterday at 11:08 PM
Ah, ok, well, if that's a valid use-case for you, then i'd suggest you consider maybe a more conventional chat service - whether its matrix, xmpp, etc. - because i'll be honest, and with all due respect, if you're trying to get ntfy to be a 2 way chat, is that not sort of like trying to use a shoe as a hammer? I mean, it will work, but will it do so effectively enough for your needs?
yesterday at 11:35 PM
Email?
yesterday at 5:00 PM
you should look at celld
yesterday at 7:30 PM
>I'm searching for a simple, self-hosted chat system that allows me to host unlimited bots and send messages (with notifications) to my iPhone easily.
I do this with IRC. I used to have a blog post up about it, back when blogs weren't just training data providers for LLMs, but I'm afraid it's been deleted.
tl;dr IRC works great, but you need to wire up push notifications. For android I used pushbullet, for iOS I am still evaluating the alternatives but pushover looks okay. IRC itself is nice because the protocol is shit simple, to the point that if you can type fast enough to respond to the pingpongs you can cosplay as a bot using nothing but telnet. As a text protocol it's easy to inspect and doesn't require binary decoding of packets for debugging.
I recommend the Ergo ircd. It ships as a single binary (golang), can support tens of thousands of clients, is at the forefront of the ircv3 modernization initiative, and is under active development.
yesterday at 11:16 AM
I quite like this, but it feels like spam could quickly become a concern.
yesterday at 11:19 AM
That is always a concern, yes. You can block users, and entire instances, that spam.
yesterday at 12:13 PM
I had a pseudo-plan for something like this but for reasons related to privacy I had two types of chatrooms:
* regular chats, existing only on the server, no leaking the chat transcript except via users, but never via server to server.
* chambers: a global chatroom, located at a server, maybe with a MQTT anyone could subscribe to.
This never left the early planning stages though, but I thought the segregation between federated chatrooms and regular chatrooms was of interest to keep in sync with IRC open but closed nature of chats.
yesterday at 12:14 PM
That seems to be similar on this one. &room is local, while #room is federated.
yesterday at 1:35 PM
Did not see that. Thanks for pointing that out! Will re-read the page.
yesterday at 11:56 AM
Vibecoded?
yesterday at 12:41 PM
clearly.
yesterday at 8:21 PM
As someone very critical of mindlessly vibecoded software, I've worked with James (@prologic) years ago and very much respect his craft. AI assisted or not, I wouldn't describe him as a vibecoder. He's a great engineer.
today at 12:39 AM
[dead]
yesterday at 12:47 PM
Instead of a separate federated network for a single app, why not implement the app on top of a pre-existing federated network, so that nobody has to create yet another account? Like, on top of atproto or activitypods or...?
yesterday at 12:55 PM
Or matrix
yesterday at 4:02 PM
A lot of the design reads like almost but not quite ActivityPub.
yesterday at 10:57 AM
yesterday at 11:19 AM
Both cool and worryingly convenient for the botswarms we've been warned of...
yesterday at 11:46 AM
Give me a day and I'll implement it in my agent-oriented IRC server https://github.com/marlinski/airc !
yesterday at 1:16 PM
Cool. I did something like that so agents and people could communicate with a Jira instance using Websocket-aware IRC and a browser-based client based on superchat.
Put the issue context in a #channel and invite external parties/entities, bring the results back to the work.
I have tested it but the complexity didn't justify the results in my experiment. I couldn't get it accepted into Atlassian Marketplace, either.
yesterday at 6:07 PM
> "Scrollback that follows you rather than your client"
This form of LLM speak annoys the absolute shit out of me. It's a bot trying to emulate the worst reassuring sales copy you could imagine.
yesterday at 1:06 PM
Besides not having C runtime linked (which is great for scratch/distroless Docker images) - any other advantage of using a pure Go SQLite instead of the C binding?
yesterday at 10:47 PM
[flagged]
yesterday at 11:17 AM
This is exactly what i was thinking about for the last few weeks (but am too stupid to implement myself).
Itâs like email just for IMâŠ
yesterday at 12:13 PM
You're in luck: Some people already thought of this, submitted an RFC to the IETF and implemented it. It goes by the name XMPP.
yesterday at 11:45 PM
XMPP is terrible though. To be fair so is email. And activitypub. Maybe federation is just terrible.
yesterday at 11:22 AM
Many earth rotations ago, I was IMing through an mIRC bot because I refused to install MSN. This kind of reminds me of that too.
yesterday at 11:39 AM
I used Bitlbee until not that many earth rotations ago - it's an IRC daemon that provides bridging of various other chat protocols. It worked way better than you would expect, especially back in the day when you could use XMPP to connect to the various proprietary chat services.
I didn't stop using it until I stopped caring about those chat services.
yesterday at 12:01 PM
These days I run a Matrix home server with bridges to Slack and WhatsApp so I can use fewer chat clients.
I do wish the Matrix client situation was less messy.
yesterday at 1:12 PM
is there a list of public instances one could join somewhere? I kind of want to dip into irc again. it was peaceful.
yesterday at 1:40 PM
The idea (what's encouraged) is that's so simple you can run it yourself. If you email me (email on profile), I can create an account for you on mine.
yesterday at 5:19 PM
This is pretty much just a reinvented Matrix protocol. Nearly identical.
yesterday at 6:09 PM
To be fair, if i recall correctly, some of the folks who started up matrix protocol (and associated project) came from/and loved the IRC world (e.g. the rooms concept, etc.)...so it stands to reason that matrix and irc have at least some *conceptual* similarities, and hence other stuff that spins off from or leverages IRC may also appear similar to matrix.
yesterday at 11:38 PM
Matrix feels more like decentralised Slack/Discord. There are two different pits of success you can fall into with messaging: direct delivery to recipients online right now, or maintaining a shared history and syncing it to all recipients whenever they come online. IRC is the former, and almost everything else is the latter because the former doesn't work on phones which are the supermajority of all end devices.
today at 12:02 AM
Page blocked by firefox lol
yesterday at 4:03 PM
Parlay?
yesterday at 3:36 PM
IRC is popular because itâs bad. I donât believe there will ever be a replacement for this reason.
yesterday at 10:48 PM
[flagged]
yesterday at 2:33 PM
yesterday at 2:09 PM
But isn't IRC already federated?
yesterday at 2:16 PM
You can link servers (Libera, for example, has many), but they are not federated, nor decentralised (services are used for registration, etc.).
yesterday at 3:49 PM
Closed federations. Only trusted servers
yesterday at 12:35 PM
The connection to git.mills.io was interrupted while the page was loading.
yesterday at 12:39 PM
Sorry, I am sure it is the HN effect.
yesterday at 11:23 AM
lol, so XMPP, but instead of XML, it is IRC. Alright, I dig it.
yesterday at 12:27 PM
Instead of TCP+XML it's HTTP+JSON
The IRC is just a front end. Could use any front end
yesterday at 6:22 PM
I see. So more similar to ActivityPub.
I wish them the best of luck. Federated systems struggle to achieve critical mass, and if they do, large corporations tend to snuff it out. I distinctly remember Google committing to The Microsoft EEE strategy with XMPP. We've left behind lots of great ideas in the last 20 years
yesterday at 8:36 PM
Google helped make XMPP quite popular for awhile, then killed their own product and left us with a lot of useful specs they had contributed. So I'm not sure I'd call that EEE
yesterday at 3:31 PM
[dead]
yesterday at 3:09 PM
[flagged]
yesterday at 3:45 PM
[flagged]
yesterday at 11:35 AM
[dead]
yesterday at 1:15 PM
[dead]
yesterday at 12:13 PM
I recall this bait and switch. It was called Slack
yesterday at 12:44 PM
Slack is pretty centralized, and also closed. You can't self-host at all.
Slack is a *different* bait and switch.
yesterday at 2:20 PM
Different use case no? I thought slack was enterprise focused from day one.