Yes, that is correct. I suppose 'isolated instance' is the term I am reaching for.
If I configure my web server proxy to block snac2 from sending and receiving connections from other instances would this break snac or cause some kind of dump or race condition? I suppose I could just try it and see.
Is there any internal method for preventing a snac2 server from federating? I don't mean blocking. I mean prohibiting all federation and contact with other activitypub instances. The goal is the local users don't see anything from the fediverse and the fediverse won't see anything from the local server.
I realize there are brute ways to hack nginx and IPtables to block ports and things like that. I'm just wondering if there is an internal method that is more sensible, or if perhaps some blocks of code could be removed before compilation.
Ich folge ein paar fur deise; dann lese ich fur lehrnen.
Gestern gelernt ich das wort, "Hilfeleistungsloschgruppenfahrzeug.". Dieses Wort ist urkomisch. Die sundet ausgeseichnett aber zum sprechen ist fast unmoglich.
I couldn't say. I don't have time to examine the project or test it. I think the combined endpoint routing is a strong idea the way their documentation explains it. Allowing users to choose longer circuits is also very good, and we used to have that in Tor a long time ago. Veilid can probably can be made quite a bit safer than Tor if an app network includes a good number of nodes.
The keyed network option is a great idea. I can't overstate how important it is to be able to have private mixnets or mixnets run in cooperation by consortia yet segregated from public access. From the documentation it looks as if the users can slice and dice for their own recipes.
One thing I think could be added is swarm routing for larger networks. Instead of sending data through a route or circuit, the data is chunked into equal-sized payloads and shuffled through a swarm of randomly-chosen routes in longer routes. This would be a nightmare for eavesdroppers, requiring much more in the way of compute power and honeypot peers for statistically correlating endpoint IP addresses.
Another problem exists with mixnets and I don't see anyone discussing this problem. In a peer-to-peer mixnet anonymity is supposed to be achieved by tunneling through multiple peers. The theory is that each peer in a circuit can only know the adjacent peers, and thus not be able to correlate endpoint IP pairs. However a determined adversary with large resources can spin up and run dozens or hundreds or even thousands of peers on a public network. Thus any route formed through a series of these hostile peers would not achieve anonymity for either endpoint. Since the adversary owns all the peers in the route, the adversary can use the timestamps and payload hashes to correlate the route and identify both endpoint IP addresses. Yet ameliorating this attack on a public network requires a certain number of tamper-proof peers for which all users can verify those peers have not been tampered with. The private key network option of Veilid amerliorates this attack. If the hostile peers can't join your network then they can't employ this kind of surveillance.
This opinion is just from a cursory glance. I can't vouch for anything without looking under the hood.
No. It is a document sorting and collation scheme. The designation 'greenprint' means it contains all necessary information for understanding and doing immediate implementation. It is my attempt to nix to disjointed reference materials and information overload.
Name: Byrl Raze Buckbriar (call me Raze).About: Underage curmudgeon and expert in Murphy's Law. I grew grouchy before over the hill was a thing. Neither 'glass half empty' nor 'glass half full.' I want the whole tankard. Speak not with words. Speak with work product. I enjoy crypto, ciphers, puzzles, riddles, and wordplay.Site: Cryptography project site. (https://octade.net)Publications: https://octade.net/publications.htmlORCID: https://orcid.org/0009-0009-5144-3278Netnews: Find me on #Usenet in #Newsgroup alt.rhubarb.Git: https://codeberg.org/OCTADEKeyoxide1: https://keyoxide.org/0CF7084CF97B85F2ABF97010C6663A42C56F5F0EKeyoxide2: https://keyoxide.org/B9B2A8EC2C4B20D2011CFEAA07E4A7FFF6585E8FBlueSky: https://bsky.app/profile/octade.bsky.socialHackerNews: https://news.ycombinator.com/user?id=OCTADE#bible #crypto #cryptography #cryptology #ciphers #conlang #retro #bash #pascal #random #usenet #simplicity #encryption #privacy #linux #bsd #hacking #poetry #math #writing #research #tinker