superhighway84 VS tauri

https://github.com/gravitl/netmaker

Honorable mention:

SuperHighway84 - more of a Usenet-inspired darknet, but I love the concept + the author's personal website:

https://github.com/mrusme/superhighway84

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.

Someone created a Usenet-like thing on IPFS. https://github.com/mrusme/superhighway84

It's kind of dead. IIRC the dev put that on the back burner in favor of a new BBS-like app. https://github.com/mrusme/neonmodem

If anybody wanted to, anybody could start a RLM SuperHighway84 where we could just talk about RLM stuff all day.

SuperHighway84 - Is this handy for organization? I like the usenet-style where it sorts itself if people use proper newsgroup names. If people used a 'youtube.channelname' format at least people could maybe scroll down to channels/videos people are talking about.

In my mind something like superhighway84 would be a better platform, then it's automatically organizing itself to some degree if people post in appropriate newsgroups. People looking for lost youtubers could post in youtube.channelName. That person looking for old VCDs & screeners could post in vcds.screeners.

SuperHighway84 is like a usenet style board where people can create whatever newsgroups they want. Anybody could start a 'Datahoarder' highway.

I like the idea of something like SuperHighway84 for talking about our collections. We could make one called YoutubeGraveyard or something. There's also r/DHExchange

Have you heard of SuperHighway84?

Hi, dear Tauri! Long time no see. I published my first post, Developing a Desktop Application via Rust and NextJS. The Tauri Way almost a year ago. Since then, Tauri has become stronger. I'm happy about that! And now, I am very pleased to make a useful contribution to the Tauri community. As a full-stack developer, I frequently face situations where I need to start a DB-based UI project as fast as possible. It's stressful if I need to start the project from 100% scratch. I prefer to keep some boilerplates on hand, which will save me time and nerves and will be the subject of this article.

Hey Thanks!

Just electron & vite. I might actually migrate off electron, Tauri (https://tauri.app/) seems to be getting more stable and it's gotten great reviews.

I think this is the boilerplate I used though https://github.com/cawa-93/vite-electron-builder.

Well the great thing about WebAssembly is that you can port QT or anything else to be at a layer below -- thanks to WebAssembly Interface Types[0] and the Component Model specification that works underneath that.

To over-simplify, the Component Model manages language interop, and WIT constrains the boundaries with interfaces.

IMO the problem here is defining a 90% solution for most window, tab, button, etc management, then building embeddings in QT, Flutter/Skia, and other lower level engines. Getting a good cross-platform way of doing data passing, triggering re-renders, serializing window state is probably the meat of the interesting work.

On top of that, you really need great UX. This is normally where projects fall short -- why should I use this solution instead of something like Tauri[2] which is excellent or Electron?

[0]: https://github.com/WebAssembly/component-model/blob/main/des...

[1]: https://github.com/WebAssembly/component-model/blob/main/des...

[2]: https://tauri.app/

Welcome to the 2nd episode of our series “Building with Tauri”, where we chat with developers who build amazing projects and products using Tauri.

Tauri seemed like the "thing" I should switch to because everybody loves Rust (heh), and because it ships significantly smaller apps.

First of all, I will be using npm as my package manager but feel free to use whatever you prefer. Find more info here.

Today I'm talking about Tauri! Do you know all the various tools that allow you to develop native applications starting from web languages? They often need an intermediate compilation, in the middle of which you end up encountering various problems not always transparent and directly solvable with a language mostly detached from native development. On the other hand, there's still the ease of developing attractive and easily usable interfaces, which are more difficult to develop with low level languages.