Would this work have the potential to speed up encoding/decoding of the PAR2 format[0]? This format is widely used to protect datasets against bitrot and small losses, but is held back because of the significant compute overhead when dealing with large datasets.
Unless I am badly misunderstanding the paper, this is about doing matrix multiplication on matrices whose entries are large integers. So far as I can tell, PAR2 doesn't do any large-number arithmetic at all, so I don't think this work will have any relevance for implementations of PAR2.
[EDITED to add:] Reading the paper a bit more carefully, the above isn't exactly right. It is about doing matrix multiplication on matrices whose entries are "large" but they're interested in using the idea for hardware design where "large" may mean not-very-large, building (say) 16-bit multiplies out of 8-bit multipliers.
But for software implementations (and I doubt anyone will be making special-case hardware for PAR2) small multiplications are not generally faster than large ones. Maybe you might be able to do more of them in parallel using SIMD, but I bet the extra additions and subtractions and general overhead would outweigh any gains in that setting.
This tool is amazing for us. There's so many pieces to this - the capability is a big step forward for architecting databases.
Rudimentary compared to what you've done, but is it possible to take an existing database schema, developed either in the Supabase migrations style or another tool like Flyway, and draw the diagram? That alone is huge for us in an enterprise setting, and would allow us to communicate the structure of the database to business folks (especially large databases). How does the tool build that from migrations currently?
> take an existing database schema, developed either in the Supabase migrations ... and draw the diagram?
It might not be so obvious, but this diagram tool is already built into the Supabase Dashboard (under "Database")
I can see some value in providing this as a generic service for any PG database - I'll look into it - but I know that Dbeaver already has something like this built in (and I think pgadmin too)
Our scenario is trying to produce a diagram during CICD. We have ongoing changes that happen to our SQL codebase, and it's a constant problem to align our documentation and diagrams to that. If we could see the current ER diagram of 'main' branch, and ideally also any given historic commit, it would be huge for our product owners, as they could consume the diagram and understand the current schema without disrupting the engineers. The CICD pipeline would ideally spit out a static page of the ER diagram during build, either as SVG or HTML.
Dbeaver and PGAdmin's diagramming functions aren't anywhere near as advanced as what you've built here, and fall apart for large diagrams. Your team has a lot of smarts!
I was interested in how you do authentication, but currently the 'Omni_web' link & readme is missing. Suggest you could use the pgjwt[0] approach for this for simple logins in the short term, but supporting OpenID Connect would be a larger engineering effort.
The current approach employed by Omnigres users is good old sessions (since latency to the database is non-existent) and omni_txn's transactional variables (https://docs.omnigres.org/omni_txn/variables/) to store session-related data.
This way we don't need to handle the difficult parts of JWT (forced expiration, etc.) and the mental model becomes rather simple.
Also forgot to say, love the project and love the objectives! Allowing Postgres to do it all means so much from a server management perspective - imagine not having to manage any redundancy/performance/analysis outside of the health of the Postgres box - fantastic :)
Thank you for your kind words! The original dream was indeed a "one box" approach, even when they scale horizontally and to the edge. Perhaps a more accurate depiction of this is a "unified interface".
Could I ask, with these p2p/federated projects (and thank you mrusme for helping me to get superhighway84 running! dope personal homepage, big fan of yours) why doesn't anyone use Usenet itself as resilient backup storage?
The Usenet network itself is always online and highly resilient - most providers offer ~5000 days of binary retention, and endless retention on text - and great bandwidth to boot. If a user doesn't have Usenet, or the Usenet isn't at the 'current' timestamp, that's where the Tor/P2P layer could kick in. You would only need a single server (with a private key, trusting the public key in the main executable) that continuously archives new posts to Usenet to make it work.
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.
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.
RE the libraries, while it is true that I can't find anything made specifically for Usenet in Go, Usenet itself is just an extension of the Telnet protocol[0], and there are Telnet clients in Go[1] and Node[2]. It probably isn't simple, but I'm sure working with OrbitDB wasn't easy either!
RE the resilience of content on Usenet, the vast majority of binaries are heavily encrypted, and doesn't make sense to anyone without the key, despite being conveyed en-masse between the world's 10-ish full-scale Usenet backbones [3]. I'm proposing that the backend of a service that makes use of Usenet could be similar, with a single 'background server' on one trusted machine enough to continuously push the history to Usenet. A regular user client could then search for the latest version of this history and quickly refresh their side from Usenet, regardless of the status of IPFS at the time.
RE democratic access to technology, at least with Superhighway84 it was very expensive for me to actually run the software, as I have a small allocation of bandwidth from my ISP and not much I can do about that in my area, and I ultimately had to delete it due to ongoing transfers of 3GB/day running the IPFS node. Quiet itself notes a limit of 30-100 individuals with its application - I'm proposing that using the one remaining federated multicast technology with some modern encryption might help with issues around blasting data everywhere from a bandwidth-constrained environment. I know that definitely in Africa, there are ongoing issues with bandwidth and networks that we forget about in the West. Usenet, with extremely lean network overheads, could be part of the answer.
I do agree with your vision of a future of truly peer-to-peer technologies, but for those of us who are bandwidth-constrained or otherwise limited in our access to those technologies, having a technology-agnostic application that just 'does magic' to do whatever it needs to do with your content is what's going to make a majority of users happy.
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.
A quick note on Quiet's capacity limits: the 30-100 number is very conservative and not an intrinsic limit of the approach we're taking.
I'm pretty confident that we can get Quiet to the point where the practical limit of participation in any Quiet channel is storage, relative to the amount of message history that a particular community wants to hang on to for a particular channel.
It wouldn't be crazy difficult to shard storage either. Once we do, a community could store a lot of data by marshaling many nodes with low or uncorrelated downtime. Paying for storage is also an option.
RE contributing to neonmodem, I was thinking about it! But baseline NNTP, as it sits today, is a fetid pit of spam, and I don't think it would add value. In fact, spam is, I believe, a far bigger problem with these networks than the technical distribution of messages over P2P. I took a sample of a random Usenet group today: [0] - but I really struggled to find one to post an image of here because even a lower-spam group that I found (e.g. alt.politics.uk) was full of profanities in the subject lines of the posts.
I think superhighway84 remains no/low-spam because of the technical hurdle of connecting. I don't think you've got any inbuilt spam protection? Plebbit [1], full of spam. The innovation of Reddit is arguably that people love the power-trip that comes with moderating a reddit group, and will do it for free - there's been no shortage of moderators to replace the protesters in the latest rebellion [2]. Hacker News, where I get to talk to smarter people than myself - very well/heavily moderated [3]. The SomethingAwful forums just resorted to charging everyone $10 for an account when they started having a spam problem, and that happily paid for the hosting costs and a life for the main admin for years.
To deal with the spam, you need some kind of filter where users can't just create thousands of accounts, especially in the age of LLMs. Logging in with a social account is the obvious one - Github/Facebook/Google have expensive processes in place to reduce the deluge of spam accounts, but some obviously creep through. Do you then run on an algorithmic chain of trust, promoting posts based on the quality/ratings of the individual's contributions elsewhere? If you do this, you're creating a system to be gamed. Running on invites only is another potential solution, but then it's difficult to start the gravy train of quality posts - who wants to apply effort to talk to nobody? Do you instead run a pyramid scheme - charge $10 upfront, but give a share of the site's ongoing revenue to those who get their posts upvoted, Twitch/Youtube/Instagram style? This to me seems like the one solution that could potentially displace Reddit, but I lack the personal belief/gusto to make it a reality.
Even if you managed to register and motivate a thousand decent posters, I don't have a clear view of how you keep topics on track within a group without a human moderator, but some research has been done in using LLMs to pre-rate posts based on the history of the group. But if the LLM is agendaless, you obviously get a groupthink echochamber. Give it an agenda, and you start dealing with bias - not every post of value is war and peace, and sometimes you just want to thumbs up a funny cat.
Please forgive the above musings if they're low value. I feel like I have no answers, only problems and questions, and I believe I'll be posting on Hackernews for tech, Instagram for comedy, and Facebook groups for special interests (e.g. car repair) for some time to come.
It isn't like farmed salmon is a crucial staple food without substitutes - nobody will starve without it. There are plenty of other fish breeds that are less damaging across their production lifecycle.
Farmed salmon is a luxury good and we shouldn't be harming the environment for that.
that's likely larger and more mature presorted units. Salmon can eat smaller ones. You can tell from the price that those cost more than actual salmon.
I am not expert, I am just speculating that if you dig into details, picture can be very different.
I didn't get who are those "we" and where it was stated and by who, and why that who is an absolute authority in this discussion that any other opinions are labeled as "irrelevant"
How did you get so many great company logos onto your website? Did each one have to go through a legal approval? Was a struggle for us at my old startup.
[0] https://en.wikipedia.org/wiki/Parchive