Virtual MultiSystem DNS/Hardware ID Scheme

[josh]

POV about economics is that the models are mostly true & insightful about virtual reality, alongside the fact that we are usually cheated & deceived in actual reality by various poor fits between VR & what is going on. So for example, the ability to charge for microservices *is* an incentive to create more available service. It is also an incentive for a corrupt or greedy municipal govt. to try & regulate to say only their service is allowed at the rates set by their hidden partners. That’s a separate problem. Here the hope is that being able to use most types of existing & next gen infrastructure makes it hard to set up moats.

[josh]

As a low end possibility for example, imagine sheep farmers in Asia who want to give hand held loran to all of their extended family & send asynchronous messages from out in the fields. They can use domain protocols which allow new devices & family members to be identified as such if that’s supported where they are. Isn’t affecting you in your NY office.

[josh]

Receipt for work is a lot different for a TCP hop, an encrypted hop, & delivering an email in this new protocol. It would be reasonable to expect the quality of the receipt to upgrade over time, stressing convenience of getting started in the beginning. We know that spam mailing can be abused – nobody is giving away infinite spam mailing for 1$.

[josh]

We should welcome more technical discussion & models of how this sort of scheme could affect Mil denial of service attacks. My POV is that such attacks are illegal, but hard to document & hard to resists & incapacitating for the people shut off. Like other mil/Heine matters, individuals are simply bullied by a broad criminal consortium.

The effect of more choices of multipath routes & less commitment makes it easier to resist attacks, potentially easier to discover what went wrong, document that, & file grievances.

NATO/DOD is very serious about fighting a complete & long lasting war on all independents, so the can work to declare that any node passing indie traffic is to be blackballed from connecting to all services they control. They may insist on that with admin, software, or hardware acts. They may do that tomorrow, regardless of these proposals. The proposals themselves make it easier to use routes & bridges where they exist and makes it much easier for that to be hiding inside a given node with low risk. On the other hand, the proposal also makes it easy for any given service provider to simply not be involved in protocols or connections they can filter out.

I don’t see problems in this category. More likely is prejudicial attacks based on sham criteria to prevent achievements of critical mass. That is like every other GT initiative. The plan is to globally grow away from & out of that.

[josh]

Dimensions of Message Routing Priority:

I. Need for low latency
II. Need for insurance of delivery to final destination
III. Need for invisibility of final dest/sender
IV. Economic cost vs. compensation
V. Need for trusted intermediary routing (e.g. worried about timing attack?)
VI. Special emergency situation trigger claim

These help inform priority queues & bundling policies

[josh]

Combining ids from recent threads on edge telecom, trust, & robot attackers…consider biz models that include 5G+ satellite + LoRaWan + ? in concealed locations on structures or trees or utility poles, etc. The relay stations are designed to draw power from batteries & environmental power & sometimes outdoor electrical if it is convenient. Installation is assisted by drones. The installation is barely noticeable. A service tech can easily reach the concealed battery sources at outdoor ground level, which connect to smaller batteries with the elevated device. The wires could be carbon based but could also include thin metal – this isn’t a black bag prank. Service techs can routinely reach the ground level batteries when needed. The main biz model is that the property owner receives a small amount of supplemental income from the network & good connectivity without needing to do anything except agree.

[josh]

Consider this model/advantage: cooperating edge units that are conserving power rather than being always at high power/bandwidth can combine protocols to help at the edge: a low power form like LoRaWan or Zigbee can be used to initiate activation of a higher power or directional antennae amplification in the upcoming workload. A kind of smart, partial wakeup.

[josh]

Interesting chart here comparses the power usage, range, bandwidth & other features of several wireless protocols.

[josh]

Topic: How Should Virtual DNS Multisystem be related to Cloud Storage/Web11? We advocate the same principles of allowing multi-system, virtualization, automaticity, optional pay-as-you-go, utilization functional cryptographic primitives for indexing etc.

These things should be easy to do:

a) Specify that particular structured content is to be virtually hosted in a distributed high availability system from ProviderX-SpecStringY

b) Copy from One Provider to Another

c) Recall/read content by unique id & Provider (or search the major providers, more slowly, if the provider is not known)

d) Do that from any system

It doesn’t sound like much, but the point is that the typical user only needs to know Provider Choice, SpecString, & have any required pay mechanism set up in order to host content all over & name it for others.

[josh]

For a web like experience – we implement pointers to content pages that are dynamically altered to include different content, which may all or in part served by CDNs, and site replication services like Cloudflare that follow the pointer to the dynamic content. The decision of how to virtualize the dynamic pointer with a mnemonic name is at one level up in implementation, but more critical & political from a human factors/interface POV. Like W3 and URLs, there will be alternative forms. Finding them is a core function of the Virtual DNS system. The choice of DNS provider methods remains independent of the forms but not fully independent of methods for distributing content (e.g. you can get mapped to YouTube in different contents depending on where you are at the moment – this is implemented by YouTube and not by the Interne infrastructure system). I leave it to others with more knowledge of the current realities to describe the set of implementations they would like to provide for that.

[josh]

A side point hear about “search” & what is stupidly limited in W3 – providing key words for a web page as opposed to inferring them with info heuristics – the very basic scheme could be a lot smarter. A simple change would be
a) Ways to see directory trees of key word topics that are commonly used
b) A basic way to assign a particular key word to a commonly used topic tree
c) convenient ways to inherit the key words of other pages, defaulting to the local tree, but allowing for other variations – i.e. “I am this set plus these additions/subtractions”

Search in various url schemes would be stronger & more efficient if those systems were in place.

[josh]

The traditional ICs used by DIA & other groups receive analog signals. In this general multisystem concept, a the form of payload & transmission is abstract so long as their are digital endpoints to coordinate the flow. This offers many different possibilities for networks that deliver an IC like experience. We list some below for stimulating imaginations:

a) traditional hardware with a locally installed node that translates the message to the analog channel accessing the hardware.

b) new GT hardware which receives data in digital form & converts to analog within hearing range

c) a bridge node that receives digital messages, translates them to analog form, & relays that to an analog IC network

d) a near body sensor kit that converts sounds or micro movements or output from neural scans to messages in a given format with a customizable addressing convention (last sender, “My friend Jerry”, etc) and relays them to configurable sources

Local wearables can come in many forms including blankets, collars, headbands, pillows, etc.

One of the key topics people are interesting in: “How do I obtain the basic, lowest cost packages that works around BOD?”

This is all doable & legal without any really unknown “mystery tech”.

[josh]

Backwards compatibility for NAT schemes, as in routers that implement NAT & Azure IoT, can be usefully worked into the Virtual DNS map to allow for greater compatibility. For example, a special gateway device may allow a nicknames to be associated with the NAT network & particular devices in a way that maps to the Virtual DNS globally through the device.

[josh]

I think it would be a good idea to include an asynchronous message drop & retrieve functionality that could span the entire range from an analog of e-mail to a bail out for temporary loss of bandwidth when streaming movies. The online storage is sometimes/often by set contract or extra dynamic fee. Making it available at a basic level in the system can help fill in some gaps.

[josh]

Another kind of streaming functionality this could help support: individual end nodes have dropouts or partial attendance in a live stream/video conference/event for various reasons – it might be convenient to compile index points into segment requests for them to go back later if they wish & review what they missed – that could be more easily supported using asynchronous online drop site/mailboxes on each end.

[josh]

Simple Task Picture:

There is a level in the system of analysis here with a caller & a callee. You can call collect. The concept is asynchronous by default with requirements for various types of synchronous/delay limitation/bandwidth as special cases. Cryptographic policy requirements and policies & preference rankings & billing accounts (if needed) etc. are things which can be specified at the caller/callee level, which, of course, is configured by higher level applications.

Inside of a call, the system can work out a lot of multi-path, hops, crypto jazz, etc as part of satisfying the call mission/policy. There are no sessions by default. So credentials are REST protocols.

A drone can act as caller or callee – it doesn’t have to be person or a company. It has another profile as a link station. They are bot implemented in the same drone.

[josh]

In the case of a severe hot ave, say other drones at various times may or may not have delivered crypto hardware to embargoed site. Probably it’s not too hard to work out protcols for doing that.

In general, the network should carry messages that are not crpto secure as quotes. [Description Says]:” ”
The id of desription is not secure in the same way. But a drone over an address, for example, can report which address is there with some degree of confidence.

[josh]

Virtual Hosts/File system/Repositiories/Websites etc. can also have ids in the same sense. Policy has to decide where to use a nonce versus cryptographic credentials. Individual users & may have many different ids they use for different roles.

[josh]

A point about flexible multiplath routing & virtual DNS that could be emphasized more:

For IC connects to backwards compatibility, we don’t need to stick with DIA,UK/Russia, or ISIS as the entire route. We can specify other intermediate transitions mapping mixed endpoints.

[josh]

In many cases, electronic traffic between parties & networks is being analyzed for routing & timing & used as the basis of decisioning making from Deep State sources to declare tag/routing/activation changes to particular macs that disable their functionality in a local or contagious way.

Occasionally, they may also reclaim old macs into new active roles.

From a GT POV, there may be extra risks/rewards associated with different routes, data volume, & timing patterns based on chances of causing tag changes to some of the macs involved. It is not practical to analyze these chances in real time. But it makes sense to use simulations & data modeling to associate risk profiles with different conditions & then internally assign those macs to different virtual network schemes for the purpose of real time routing computation.

For example DNA active friend/foe vs. DNA quarrantine friend/foe could be in different categories in the routing computation. CIA may also add extra noise/bounces to channels based on tag condition so this sort of analysis can also help with that.

[josh]

Topic: What would an improved version of Onion Routing look like in the message oriented system with multipath capabilities?

We want to support something like P2P communication between A & B that may include system level cryptography analogous to SSL, cryptographic tunnels analogous to VPN, hiding of routing, multipath routing where available, robust error detection/correction & resistance to timing attacks. These things are all independent of whatever message level cryptography A & B may choose to employ at the application level. The network can/should support the use of Tor analogous onion service in a native way.

Any specific security option may be unavailable at some locations or too expensive in performance terms or some other criteria to justify current message usage.

A flexible algorithmic scheme might be implemented by the concept that all routing decisions can be made by consulting decision lists of the form:

If Options X,Y,Z are available & the overall/added cost is less than [C1,C2,C3…] then choose that option..

Else if Options X1,Y1,SZ1…. then choose that option…

Default Case (could be failure)

So for example, something like SSL might demand end to end SSL or simply SSL between trusted hops. Mitigation of timing might demand certain types of storage/delays or message parcellation/multipath at last hop. But these are esoteric “headers”. Where used, they could be in front of messages and stored for a time with an index in case of a need for negotiation or optimization by caching of familiar index patterns. The tunnel protocol may also demand the use of encrypted noise when idle to help mask traffic bumps.

The prior proposal for open multiprotocol support should make it ez to add these sorts of onion like protocols to the set. The decision list structure on costs coupled with node availability may lead some hops to unwrap the onion b4 the end. The decision list structure should make it ez to say if this is permissible. Perhaps some sort of failure warning should also be included as an option. Choose of VPN-like tunnel credentials/method_thereof should also be supported by options.

[josh]

For best security, intermediate nodes along a route should not receive the identification of the endpoints. As far as they know, they are completing an interiorsegment. Again, that’s an extra cost optional improvement that makes a difference in case of e.g. traitorous spy nodes on the route.

[josh]

How to efficiently implement that?

One model is analogous to having trusted nodes that act as mail servers – they anonymize which local box hosts/temp_stores a particular message, but the server itself is non anonymous as an endpoint. The mail protocol can include push capabilities, so extra asynchronicity is not required.

[josh]

Affiliated gangs of “mailbox servers” may coordinate their activity – is it better than trusting a particular 1??? Not logically. An additional level of secrecy & cost would be requiring crypto anonymous fetch so it really is asynchronous mail, but with strong P2P hiding.

[josh]

Pools of last leg & first leg servers could operate as another level of virtual DNS. Any given message in the onion could be see as a message between InputSectorI,CurrentIndexJ to OutputSectorK, CurrentIndexL created at TimeStamp t1. The sectors & their virtual onion mappings could rotate, and each sector server is on scouts honor not to leak info about the mapping under the virtual 1. So figuring the actual P2P is extra difficult. Again, it’s possible to associate serve at each end point with cryptographic keys and if the messages are only pulled, then the directories don’t need to know the actual route designate. So those are 3 semi-independent schemes – trusted endpoints, crypto secret fetch option, and obscuring virtualization of the endpoint virtual name to rest of the route at each end. Crypto fetch seems like the best from a security POV but wasteful from the social POV of encouraging too much mailbox polling in the overall user pop.

[josh]

Maybe break it down this way:

Clients may utilize one or more trusted virtual message servers for both send & receive.Clients can choose among several variants of “tunnel” protocol with each server:

a) Only Crypto Fetch
b) Only Push when set to “Active Reception Mode”
c) Keep Alive Beat with user parameters while in “Active Reception Mode”. Parameters are
i. status frequency – every N nanosecs a note will be sent saying if there is other reception traffic or not
ii. socket mode or message only mode for the tunnel implentation
iii. Bundling/delay prefs for when messages are available until when they are pushed – client can choose to time their own fetch when they know something is available
d) Fake Client behavior – a pure client can choose to mimic the network appearance of parts of working server behavior if it is not itself a working server. This involves faking client behavior on the part of some other trusted servers.
e) Require that the server used be operating in a mode where it is not receiving message origin info as part of its routing header info – that info has been blanked out (potentially mandating some extra hop for the routing). In this case, has is traffic control related to origin implemented? Seemingly, some sort of filter coalition is required.
f) Requiring an originating servers to remove info about the message sender – again, it seems that the trusted origination helper would need to participate in some coalition of filter/blockers.

This form offers increased message routing secrecy for networks with larger numbers of network participants.

[Josh SternModerator]

People should understand that BOD is literally the FBI’s favorite tactic & largest work focus, & that their general plan is to provide it at the surround the residence/work/known server level for all key GT people of interest. Using multipath to help means providing multipath for the last mile. That’s one of the key points about how hover drones for communication can help.

Side point about killing sockets: it may help to have a checksum protocol that supports ez resumption of misses inside of a crypto protocol that provides a more thorough inspection of message integrity, inside of a message oriented cryto tunnel.

[Josh SternModerator]

In my frustrating isolation tank, I receive a lot of IoT taunting & threats and abuse from Deep State predators, along with the occasional environmental noise or EMF gesture or words from the furnace/ventilation system or variable speed electric motors that I can interpret as a short message from allies.

From there I try to work backwards towards guessing what are the problems GT still struggles with. I think, perhaps, one of them is this:

I assumed allies would be granted rich IP access from phone, computer, org, etc. I assumed we could afford this. Not being part of the Deep State slavery, missing person, ID hopping, pay with coupons society, I did not understand that many indies have no easy way to register for such services in our totalitarian state and prefer the convenience of sticking with the intercepted, Deep State mafia controlled, govt. manufactured system of IC’s and grid networking that was forced on them for free as a condition of conscription or predatory employment by the Nazi govts.

Okay, my bad. But we still need robust, multi-path systems with actual crypto and biometric security – INCLUDING TRANSMISSION OF FACTUAL TEXT!!!!!. Not govt. run-broadcast-when-&-how-spook-feels-it-helps-spook to route a tiny, editable message for artistic interpretations. Can you dig that?

I am absolutely in favor of adding local wireless transmissions to on-body EMF interface as a convenience and extra capable peripheral. That’s an independent tech issue which is not a problem & which we focus on growing to 10000x better than what folks have experienced so far. It’s a different point from the reliability and integrity and availability and timeliness of the point to point messaging and who gets to use it and be identified securely and correctly.

So here, tonight, I am scratching my head for a fix. How about this one:
Organizations may choose to grant messaging capabilities to allied affiliated individuals on whatever terms they see fit, so long as that complies with all applicable public laws. There is absolutely no requirement for these to be big organizations. They do have to abide by service agreements with their 3rd party providers on whatever contract terms exist between those pairings.

If your org can only afford some low rent LoRaWAN devices on loan, then do that. Don’t use the HMS Queen Elizabeth or whatever else the Navy is switching.

Multi-path robustness is still a key.

Other points:

In modern networks, hardware principals are more numerous than person principals. Personal hardware principals can help with the biometric/secureID problem. That can be part of your network of whatever size. The system adm plane should be able to say who is and is not on current rosters. Different orgs can make cooperative agreements between each others. The e-mail system is a very clear precedent for most all of this.

Now help me see what else it is that I am missing.

Highlighting other points which may not be 100% clear

[Josh SternModerator]

We haven’t mentioned Citizens Band Radioas an extra multi-path for system run data

But hey, look, it’s mostly empty in many regions and travels further than WiFi. Certainly can be used for exchanging codes, text messages, etc. and checking for liveness.

Ham Radio is quite a bit more powerful than CB as a tech, but in the US and other domiciles, both equipment and owning operator must be officially licensed by the FCC.

Strategy there would be to get a sneaky bridging equipment somehow certified first before any wide application.

[Author]

Posts