mrusme

How?

I'm a fan and active user of XMPP. However, it unfortunately is true that encryption is a can of worms. OMEMO should be the standard, yet there is fragmentation in terms of the specific OMEMO spec version that clients use. Not even the most prominent clients keep up with the latest spec, as can be seen here [1]. One of the issues is, that everything prior to 0.4.0 uses AES-128-GCM, instead of the standard that is used by other platforms (eg Signal), that is AES-256-CBC with HMAC-SHA-256. In plain English this means that most mainstream XMPP clients do not offer encryption at a level that can and should be expected these days.

[1] https://xmpp.org/extensions/#xep-0384-implementations

It just so happens that France is the country producing over 50% of the EU's cheap nuclear electricity.

Some might not know this, hence I'm pointing it out: There's an ENV variable that you can set in your dotfiles [1] to make the Go tooling skip any proxy and instead access the the module's repository directly:

export GOPROXY="direct"

I've had this in my ENV for a long time, primarily because I don't agree with how the Go proxy operates. For teams/organizations, as well as CI environments it also makes sense to set up an own proxy [2] and use this variable to let the toolchain use that instead.

While this wouldn't have completely prevented this incident from having an effect, I would argue that it would have at least minimized the impact.

[1] https://github.com/mrusme/dotfiles/blob/772f09615cdcac94fec9... [2]: https://github.com/goproxy/goproxy

You have built a beautiful TUI, hats off. Having that said, however, if feels like a missed opportunity for this project to use an SQLAlchemy-based database backend over the more simplistic and widely supported ledger [1] format. While I understand that the your tool might not want to leverage the full complexity of a double-entry accounting system, as a friend of plain text accounting [2] I would have preferred a format that I can alter with existing tools, in order to be able to integrate _Bagels_ into an existing workflow.

Nevertheless, the TUI looks very clean and shows nicely how powerful the Textual application framework is.

[1] https://ledger-cli.org [2] https://plaintextaccounting.org

Thank you!

I once built a firmware for the Pimoroni Keybow with it: https://xn--gckvb8fzb.com/projects/kiwi/

Unless you want to impose blurry fonts onto your visitors, this font won't be it unfortunately. The required increments of 11px to display a crisp font with DepartureMono makes your content either too small (11px) for most people to read, or too large (22px) to look good.

I am always saddened by landing pages like this, because they communicate an idea that only works in very specific cases. Are you looking to use this font for a similarly polished, "Apple"-style landing page that is form-over-function? Then this font clearly is for you. But on 99% of pages that have actual content on them this font likely won't work, as much as I, too, would like for it to.

Maybe the content of what their official agreement provided differed to what the tip-off was offering.

I don't often comment on HN, but when I do, it's a shameless plug[1]. :-)

[1] http://neonmodem.com

"Local-First Web Development"

"Join our Discord community and attend the next meetup"

Hmm. :-)

Kindly allow me to reply with profanity [1] to that statement. :-)

[1] https://profanity-im.github.io

Thanks!

Thank you!

Shameless plug: Neon Modem Overdrive [1] supports HN, for anyone looking for a Go single-binary multi-platform TUI.

[1] https://neonmodem.com

Thank you for the detailed description of your idea. Indeed, if you're willing to accept the shortcomings of a dedicated USENET infrastructure, then it is definitely something that could be done. In fact, I did consider NNTP for another project of mine (https://github.com/mrusme/neonmodem), which might eventually swallow up Superhighway84 altogether. If you're interested in actually giving it a try and implement a functional NNTP library for Go I'd be more than happy to make use of it! :-)

Superhighway84 it was very expensive for me to actually run the software

I agree with you, in terms of efficiency IPFS is still miles away from where it should be. Hence my feedback on Quiet, as I do not perceive IPFS to radically improve within the next few months or even years. And as you correctly stated it looks like Quiet uses some workarounds to improve on the overall mediocre efficiency of IPFS, which however lead to shortcomings on other ends:

Quiet itself notes a limit of 30-100 individuals with its application

However, this is not how P2P should be. I'd be truly curious to hear from someone at OpenSea, or Fleek, or any of the services that offer high volume IPFS hosting about their experience and gut feeling on its future. I personally gave up on hosting my website via IPFS myself -- which I did for a brief period of time -- mainly for these exact reasons.

but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies

I believe that quite on the contrary, this might benefit these people the most. Imagine not having to do the roundtrip from your phone, to a server on the internet, back to your computer, just to have a synchronized state of your address book available.

Similarly, imagine writing with someone in your city -- let's say Melbourne, Australia -- without your messages first travelling to Utah, USA, and then back again. My gut feeling is that overall congestion on the internet could even be reduced, by allowing more applications to communicate directly within small meshes rather than travel all the way across the globe and back again. That is, as soon as there are more efficient ways to deal with the overhead that is currently breaking IPFS' neck.

LastPass is centralized, which makes it safer than self-hosted sol.. oh, well, never mind. :-)

Thank you kindly, I appreciate it and I'm glad you enjoy the content! Happy to help any time.

Your thought sounds interesting, however I'm not sure I fully grasp the details correctly, so bear with me. Generally speaking though, integrating with the actual USENET these days poses a few hurdles, one of which is as plain as it gets:

Finding well-maintained libraries to do so, especially with more modern stacks (e.g. https://github.com/search?q=nntp+language%3AGo&type=reposito...). Depending on how exactly you thought to integrate with USENET servers, it might look even more meager in regard to UUCP libraries. And yes, of course you could bind e.g. existing C libraries and so on, but I'd still argue that it's not the most straight forward developer experience that you'll get -- unlike with more modern technologies that either provide language bindings or other means of integration (gRPC, websockets, etc).

But apart from this, one key difference to keep in mind in regard of especially resilience is that, with USENET, resilience depends on the number of active servers that are willing to offer unfiltered access to the content, meaning that the game of whac-a-mole is in theory slightly more predictable for an attacker or oppressor trying to limit access to the network. On the other hand with projects like I2P, Tor, or IPFS, every new client that connects to the network is also/can also be a relay at the same time, that an attacker or an oppressor would need to find and neutralize in order to successfully block the entire network.

We might as well not forget that many USENET servers are paid infrastructure these days. For someone who lives in a developed country, this might not be an issue. However, being unable to pay for your access simply because you don't have the resources, because you are unbanked, or because your government took the easy path of sanctioning financial transactions to either providers of such services, or specific payment providers in general, in an effort to curb the use of the network, makes USENET theoretically more prone to censorship than for example IPFS.

One instance where this government intervention is rampant are VPNs, which similarly rely on a legal entity that provides the server-side of the network. There are countries that have either outlawed these type of paid services altogether, or made the companies bend over, in an effort to limit freedom of access to information. In a theoretical scenario in which USENET would re-gain traction and become a more mainstream service, it would be fairly easy for governements to sanction the legal entities that provide access to the network. And there would be little alternative, as with the amount of data on USENET, it would be quite expensive for individuals to offer free, unfiltered USENET access to others. On the other hand, there's nothing that could be sanctioned with IPFS or similar peer-to-peer services. The use of this type of software might be made illegal in general, but cracking down on it, on an individual basis, is significantly harder.

Besides, the account requirement and setup for USENET also makes it more complex for an end-user to get onto the network, as compared to IPFS, where one can basically just download and run Kubo (and use a browser extension to access the local gateway). However, from what I understood, your idea would not imply each user having an individual USENET account, but rather having own USENET servers that trust the client no matter of the user that's using it, which thinking about it, might come with its own set of challenges.

I would argue that the resilience we experience with USENET was/is partially due to the the lack of interest from many otherwise censor-trigger-happy parties, simply because unlike Tor (https://www.youtube.com/watch?v=YlZZQYLIXe8) or the Signal messenger (https://www.aljazeera.com/news/2021/1/26/iran-blocks-signal-...), it's not a mainstream technology that's used by everyone and their dog.

To get back to the topic at hand, I would rather not implement USENET or any client-server-based system as a sort of backup for an otherwise P2P app (e.g. Superhighway84), as I tend to agree with what OP stated in a different comment, which is...

The thing that frustrates me about free and open source software that requires servers is: most people don't have servers! And the prevalent model for using others' servers involves a terrible power / dependence relationship. One thing that drives me to build Quiet is that I want to see a world where free software comes "batteries included" with all of its promised freedoms and advantages, for the vast majority who do not have servers.

A software landscape in which end-user applications are not dependent on dedicated servers at all, and would instead be able to directly communicate and exchange information with each other, is ideally how I, too, would envision the future. Hence, while I'm a fan and user of USENET, XMPP, IRC and so on, and I have the knowledge and can afford the /luxury/ of renting servers to host these kind of things, I'm far from being the average end-user. I believe that the future should belong to truly peer-to-peer decentralized technologies.

I appreciate the reply and I understand where you're coming from. Looking at when you released your first few versions of this project, I understand that the options you had at that time probably weren't as plentyful or mature as they might be today.

However, the amazing thing is, as full-of-warts as the stack we've chosen is, it isn't a clearly worse choice than the alternatives, from GUN, to Hypercore, to the Automerge space, to Braid, to Holochain, P2Ppanda, and so on.

I think far more interesting these days would be projects like Veilid, Hyphanet's Locutus and ultimately Nostr -- even though not truly P2P in that sense -- which already happens to have a first try going with nostrchat.io. If P2P is something that is truly desired, I feel like projects like Briar (https://briarproject.org/how-it-works/) have solved this with Bramble (https://code.briarproject.org/briar/briar-spec/blob/master/p...) more eloquently than it could be done on top of IPFS.

It seems like you decided to roll up your sleeves and try.

Ultimately IPFS was designed as a file store, which to me was the main reason to use it for Superhighway84. I intended to implement USENET-like file attachments and (go-)OrbitDB was merely an easier way to deal with the messages posted into the groups. However, if instant communication would be my main focus, I would rather try more lightweight frameworks (see above), especially if mobile devices should come into play eventually. Superhighway84 was never intended to leave the beautiful space that is the command line and hence niche-by-design. :-)

Again, I will definitely keep an eye on Quiet, to see how it ultimately evolves on top of IPFS. I could nevertheless imagine it being overtaken fairly quickly by other projects sporting a rather lightweight and more managable basis, that allows for increased development speed and ultimately for faster iteration on features that users might wish for (e.g. DMs, @-mentions, message deletion, mobile clients, you-name-it) -- without the need to invest heavily into e.g. performance (or reliability!) issues of the underlying framework.

I'd like to point out that you probably cloned https://github.com/ipfs/kubo there, which is only one part of what accounts for the "IPFS codebase". If you want to find out the actual LoC, I'm afraid you will need to dig through https://github.com/ipfs/kubo/blob/master/go.mod and pick everything that's github.com/ipfs/*, github.com/libp2p/* and github.com/ipld/*.

While I do like the idea behind a P2P E2EE chat, I believe that unless you're willing to invest heavily into OrbitDB and IPFS, this project will stay niche at best.

The performance issues that come along with running OrbitDB/IPFS on a machine, let alone a mobile device, are still significant unfortunately. Adding Electron on top of what is already a heavy-weight application is probably going to make people's devices go brrrrr all the time. Not only that, but I would argue that for instant communication this stack might not be the best idea in terms of performance in first place.

Besides, the way IPFS has been (and still keeps) changing their dozens of libraries doesn't make development particularly smooth either. OrbitDB is always behind the latest IPFS version due to all these changes that are being introduced. Hence unless you're planning to allocate developer time on these two things as well, my guess is that you probably won't have too much fun with your back-end.

The integration with Tor is another thing that will likely be a time drain for developers, as other people here already pointed out, and that will lead to even more performance issues down the line.

Don't get me wrong, I really like the idea behind this project. However, I feel like the aspirations are unrealisticly high and the actual outcome might be realtively frustrating for the average end-user. Having that said, I would love my gut feeling to be proven wrong!

Disclaimer: I'm the developer of Superhighway84 (https://en.wikipedia.org/wiki/InterPlanetary_File_System#App..., https://github.com/mrusme/superhighway84), a USENET-inspired, uncensorable, decentralized internet discussion system running on IPFS & OrbitDB.

:-) High five then, I guess.

It's not even so much about the actual ideas or projects, because these are usually very much related to the setup that I've met the person(s) in. Everyone has ideas and at some point there was something were multiple people were (at least initially) passionate about. However, it never really stuck.

I've read about the afterpay guys and found it pretty fascinating, so maybe it might not even be the best idea to look for team mates in actual team mates, but rather somewhere totally different?

However, just checked your profile, I find it fascinating that you nevertheless pulled something off and launched an idea on your own then! How was it going and has this maybe helped with making connections to people that might be interested to work with you?

Oh my. This person didn't even get Ubuntu working properly and simply gave up to... use Windows? Instead of macOS? Because they couldn't get their setup straight on Linux?

I don't know what's more frustrating: Reading through this nonsense or seeing it got upvotes.

Even the hardware selection makes no sense at all, with no component but the non-functional GPU benefiting from the X570. The selected SSD is Gen3 and the CPU is a lower-end Ryzen where there's practically no difference between e.g. a X470 mainboard compared to the X570, when overclocked. Also overclocking is probably not what the author intended to do anyway, since there's no info on the cooling whatsoever, making statements like this even appear even more uneducated:

While portability is definitely a problem with desktops, they also have some cool advantages like: > - They don’t overheat

Clearly the author followed an "let me get the flashiest stuff that is available on Amazon right now"-approach and didn't actually take the time and effort to put together components that actually make sense.

For example, it would have taken literally a single quick search on the search engine of your choice to find at least one Phoronix post about a more recent AMD Radeon RX model that runs perfectly fine under Linux. Not to mention that "StarCraft II, Tomb Raider, Diablo III, etc" (titles that were release ~2010) don't even need a dedicated GPU and would run just fine (>30fps) on a AMD Ryzen 7 5700G APU. In fact, this whole computer could have been a $700 AMD NUC (see "Aspen") and would have been perfectly fine for the workload described by the author and actually run a smooth Linux experience.

Linux is not bad at hardware, it's you that's bad at planning and implementing a solution!

---

This comment was written on a modern Gentoo Linux Ryzen 9 machine with a flawless Wayland setup and perfectly fine 3D hardware acceleration on an AMD GPU.

Still no public statement from their side unfortunately.

Is this simply a hick-up or a planned smoke-screen tactic?

These are my ...

- computer: https://xn--gckvb8fzb.com/a-nomads-computer/

- command line: https://xn--gckvb8fzb.com/a-nomads-command-line/

- camera: https://xn--gckvb8fzb.com/a-nomads-camera/

- coffee: https://xn--gckvb8fzb.com/a-nomads-coffee/

- digital infrastructure: (soon)

... setups.

Multiple times across different European cities in the past decade up until the beginning of 2020 for the last time, after which I decided to not carry anything apart from an encrypted and passcode protected phone with me further on. Not going to finger-point the cities/countries because it could have happened anywhere and luckily it never involved the use of force or weapons.

After being robbed of cash and cards so many times I only carry my passcode-protected phone with me, nothing else. I don't have keys, cash or chewing gum.

Parler is broken by design and it was predictable that it would get to this point, one way or another.

The platform would have had to be designed as decentralised system in first place, since (especially for things like this) it's the only way to survive in the long run.

Used an Asus Zenbook 3 UX390UA-GS041T for a very long time for exactly that purpose. Ran Linux on it, loved the keyboard, didn't like the trackpad so much but since it was really only for writing (code) on-the-go it worked perfectly fine. Not sure if there's an updated version of that.