With btrfs, you can freely create subvolumes and snapshots anywhere (including nested inside of each other), you can have thousands of them without any noticeable performance impact, and you can easily convert a snapshot to a writable subvolume. I don't have much experience with ZFS, but from reading another post [0], my impression is that this isn't really doable with ZFS. And based off of rift's Readme, I think that these features are required for it to work. But I'm not an expert, so I may be mistaken about something here.
That reflinks the files, which should get you the space savings, but I'm pretty sure that that still has to recursively copy every file in the directory, which can be fairly slow if you have tens of thousands of files, whereas btrfs snapshots can reflink the directory itself, so it should be faster.
Buy yeah, this should be equivalent in most cases, since I can't imagine that many Git repos have enough files for the difference to be noticeable.
So what's the different between Hyphanet and Freenet? Only some anonymity？
I have try the River chat. I'm not sure how to find a people chat in here. It's hard.
Are there any success stories about Hyphanet's censorship resistance mattering? Beyond serving run-of-the mill copyrigh violations (and probably child porn) I never heard anything about the content on Hyphanet.
Even now when people in the US are organising against a fascist regime it's mostly WhatsApp and maybe Signal.
> What are the content patterns on Freenet? Four patterns were identified. Freenet is (1) an archive of deviant data resistant to censorship (2) a space dominated by content associated with masculinity, (3) a nonmarket space where commercial exchange is non-existent, and (4) an empty space with many requests not returning information, and many flogs abandoned. We asked a third question: How does the analysis of Freenet inform current understandings of hacker culture? Freenet, we suggest, can be understood as a type of digital “wilderness”. It is a singular darknet space, supporting a distinct set of hacker practices
Practically: people in Hyphanet blog about stuff they dare not blog about in the clearnet -- anything from radical politics (from all kinds, left, right, libertarian, …) over personal opinion pages to wilder stuff like magick (yes, in that spelling).
Not to forget the Russian Poet who’s posting daily poems with the goal (as he wrote) that those poems still survive after police knocked at his door.
(besides talk about hyphanet and privacy tech)
So yes: I don’t understand the downvotes either, because it’s a legitimate question with a pretty clear answer: yes.
You're moving the debate here. The question was "How are the goals different?" from the project leader (who ought to know better), not whether moving them makes sense.
Well I guess you think the important part of the goals is to make censorship technically difficult, without regard to if the software actually facilitates political speech at all.
Others could argue that software nobody uses for its stated purpose has failed; but you are right that is technically a different discussion than the one you started.
> Please explain how "the new freenet" tackles censorship resistance.
Primarily through the same core mechanism as the original Freenet design: decentralization and relaying requests through multiple peers such that no individual peer sees the entire request path.
The new design also supports pluggable anonymity systems such as mixnets and onion routing. In some respects these are stronger than Hyphanet's approach because relay selection can be chosen intentionally by the user's node rather than emerging implicitly from network topology.
The main architectural change is that anonymity is no longer treated as a single mandatory mechanism baked into every layer of the system. Different applications can make different tradeoffs depending on their requirements.
First, thank you for creating this project. When I was a young high school student in China, I tried all different kind of tools to evade internet censorship, including Freenet (although admittedly with little success, there was never enough peers to connect to and/so it was too slow to download anything meaningful).
My question is whether freenet is designed to be resistant for active adversaries with deep packet inspection capability, particularly like the Chinese firewall that is also observed to do statistical timing analysis of packets? Is there any possibility to apply obfuscation to the peer to peer connection? And is there any mechanism to aide peer discovery (DHT?)
> My question is whether freenet is designed to be resistant for active adversaries with deep packet inspection capability, particularly like the Chinese firewall that is also observed to do statistical timing analysis of packets? Is there any possibility to apply obfuscation to the peer to peer connection?
Freenet's transport protocol is a custom encrypted protocol over UDP, but it is not currently designed to evade sophisticated deep packet inspection or timing analysis by state-level adversaries like the Great Firewall.
That said, the transport layer is modular, and we would absolutely accept contributions adding traffic obfuscation or pluggable transports, subject to the usual tradeoffs around latency, bandwidth overhead, and resource usage.
> And is there any mechanism to aid peer discovery (DHT?)
Freenet uses a distributed small-world routing topology for peer discovery and efficient message propagation. It isn't a conventional Kademlia-style DHT, but conceptually it serves a similar purpose.
The network is designed to self-organize into a small-world topology.[1]
[1] See the "Distance" graph at the bottom-right of the circle visualization - http://nova.locut.us:3133/
The original freenet design was replicating content as it was requested. You had no way of locating "all" the copies as they would get cached "along the way" elsewhere on the keyspace when you request them.
That property was useful both for improving availability AND censorship resistance: you could not attempt to "locate" where the blocks are without spreading them.
My naive understanding of the new design is that you can have contracts that are replicated... but they still cluster around the same place in the keyspace so any capable active adversary can actively deny access to content trivially. Did I misunderstand something here?
"Anonymity: While the previous version was designed with a focus on anonymity, the current version does not offer built-in anonymity but allows for a choice of anonymizing systems to be layered on top."
the _point_ of freenet was that you could anonymously share/store information. For better or worse, that was the point of it. It also drove the UX and tradeoffs for the network.
It was slower than Kazaa/bittorrent, but it was far harder to work out who was shareing what. (if memory serves it also chunked files up so they weren;t on the same machine, but that could be me misremembering)
I kind of see "focus" in the FAQ and "goals" in this thread as interchangeable.
It would surprise me if this would not be a common interpretation of these texts alone among the readers here.
As for the general reputation of the OG Freenet in this lineage, to the extent I'm aware, anonymity was pretty much the defining characteristic. More or less everything else in the user experience suffered to some extent compared to other chat and file sharing services because of this "focus".
And? The new Freenet provides a menu of options for anonymity which is strictly better than imposing the same (imperfect) anonymity solution on everyone.
> Though reusing the name for an entirely different project with a different codebase is disingenuous to say the least.
Same project, same goals, and it's not even the first time we started with a fresh codebase - we did it in 2008.
> That won't do his reputation any good, especially in a field where reputation matters.
This drama never comes up anywhere except HN where it seems to be the obsession of a small number of vocal people who never have anything to say about the substance of the project. I don't lose any sleep over it.
And yet I still haven't seen anyone explain how the goals actually differ.
Interestingly, there seems to be very little overlap between the people giving substantive technical feedback and the people most upset about a 3-year-old naming controversy.
Only an anecdote, but I was working on a side project with another dev who wanted to use Tailwind Plus components. It wasn't immediately obvious whether this was allowed under his personal license or if we'd have to get a team license instead, though.
We decided to go with a FOSS component library instead to avoid any potential issues down the road. After re-reading the license page now, I'm still not sure.
Forgejo Actions is what Zig has migrated to. It's very similar to GitHub Actions; the downside of that is that you inherit questionable design choices, but the big upside is that migration is super easy. While they don't target 1:1 compatibility, things are similar enough that you basically only need to tweak workflow files very slightly. Our experience so far is that it fixes most of our serious problems with GitHub Actions; in particular, their runner software is significantly easier to deploy and configure, has much better target support (GitHub's runner is essentially impossible to use outside of x86_64/aarch64 linux/windows/macos; we tried to patch it to support riscv64-linux and got stuck on some nonsensical problems on GitHub's side!), and actually accepts contributions & responds to issues. My issues with the GitHub Actions' backend & web interface (of which I have many) are pretty much all gone, too, with no new issues taking their place.
I don't like Azure DevOps or it's pipelines (the yaml ones, not the classic drag and drop that is now disabled by default), but I like it a lot more than github actions. I doubt we'd ever really use github actions for security reasons, but I do prefer the explicit behaviors and templating with structure with azure compared to how Github Actions tries to solve change management with digitalisation. I can totally see why github actions would make more sense if you don't have enterprise organisation type AD/Entra + Azure though.
Wasn't aware that there was noticeably higher latency between availability zones in the same AWS region. Kinda thought the whole point was to run replicas of your application in multiple to achieve higher availability.
They also charge you like 1c/GB for traffic egress between the zones. To top it off there are issues with AWS loadbalancers in multi-zone setups. Ultimately i've come to the conclusion that large multi-zonal clusters is a mistake. Do several single-zone disposable clusters if you want zone redundancy.
At $WORK traffic between zones ($REGION-DataTransfer-Regional-Bytes) is our second largest cost on our AWS bill, more than our EC2/EKS cost. It adds up to mid six figures each year. We try to minimize this where it is easy to do so. For example, our EKS pods perform reads against RDS read replicas in the same AZ only, but you're out of luck for writes to the primary instance. To reduce this in any significant way can eat up a lot of time, and for us, the cost is enough to be painful but not enough to dedicate an engineer to fixing.
This is precisely how Amazon's bread is buttered. An outage affecting an entire AZ is rare enough that I would feel pretty happy making all our clusters single-AZ, but it would be a fool's errand for me to convince management to go against Amazon's official recommendations.
I would LOVE to pitch something else I'm working on that is solving this problem in EKS, cross zone data transfer.
It's a plugin that enables traffic re-direction for any service that is using an IP in any given VPC. If you have say multiple RDS Reader instances, it will first attempt to use local AZ instances first, but the other instances are available if local instances are non-functional. So you do not loose HA or failover features.
The plugin does not require any reconfiguration on your apps. It works similar to Topology Aware Routing (https://kubernetes.io/docs/concepts/services-networking/topo...) in Kubernetes, but it works for services outside of Kubernetes. The plugin even works for non-Kubernetes setup as well.
This AZP solution is fine for services that is have one IP or primary instance, like RDS Writer instance. It does not work for anything that is "stateless" and multi-AZ, like RDS Read-only instances or ALBs.
That was the origin for this solution. A client app had to issue millions of small SQL queries where the first query had to complete before the second query could be made. Millions of MS adds up.
Lowest possible latency would of course be running the client code on the same physical box as the SQL server, but thats hard to do.
In my experience it has been relatively high variance – it does get as low as 0.5, but can be 3-4. That's an order of magnitude difference, and can be the difference between a great and a terrible UX when you amplify it across many RPCs.
In general the goal should be to deploy as much of the stack in one zone as possible, and have multiple zones for redundancy.
> In general the goal should be to deploy as much of the stack in one zone as possible
Agree. The can be a few downsides one has to consider if you have to fail over to another zone. Worst case, there isn't sufficient capacity available when you fail over if everyone else is asking for capacity at the same time. If one uses e.g. karpenter, you should be able to be very diverse in the instance selection process, so that you get at least some capacity, but maybe not the preferred.
I was surprised to. Of course it makes sense when you look at it hard enough, two seperate DCs won't have the same latency than internal DC communication. It might have the same physical wire-speed, but physical distance matter.
As someone not currently using Cloudflare Workers, I'm not sure I want to build a worker and figure out how to interface with it though my existing application just to send email. What happened to SMTP?
Was just about to do a demo, but Google Meet was down. Tried to use Jitsi as a fallback, but couldn't log in because Firebase was down too. Ended up using a Slack Huddle, lol.
It's more than just a few - even more basic things like rate limiting or concurrency controls are gated behind Pro. It works extremely well, but I've been reluctant to use it in open source projects because there's quite a bit in there I'd need to rebuild.
im curious about your use case -- it seems weird (to me) to use it in an open source project unless its some kind of turnkey full app -- is there a way to just release it and encourage people to bring their own oban keys? that way it looks good for the elixir ecosystem that it has found a way to support hybrid open source libraries and expands the obam ecosystem
reply