First you have to limit yourself to a specific radio variant, because the actual radio hardware is different on different esp32 variants.

Then you have a massive amount of things this "blobs" actually contain.

And last there is also a lot of continues movement integrating newer radio features. E.g newer BLE version standard implementation and so forth. So you play catch with actual new development.

This is part of the effort of Ferrocene to provide a safety certificate compiler. And they are already available now.

You are insisting here on talking about the "handle" part, though isn't the crucial part of the complete chain weather we use either did:web or did:plc?

So as you outlined yourself in the article. If you a) use did:web b) ever loose access to that domain you are cooked. No amount of handle changes can help here. If one looses a handle domain one can loose a did:web domain also, so that just moved the problem to a more opaque place.

So your identity is always either a) attached to a domain you might loose b) to some plc provider that might stop work for you.

Please correct me if i get anything wrong here, as that is just how i understand it.

We have this cache thing via wss connections. Do they invalidate this messages from user B? Is user's A worldview now completely dead?

Owning a thing in the internet is a complicated topic i guess.

Preserving past information via copying what a user said so that it does not get lost maybe also in the interest of some users (equivalent to the webarchive). I understand that this contradict the whole "owning your data" premise, but fundamentally since it was open in the first place the thing always can be copied right?

Whatever content is produced in this "open social" network, some of it may have long lasting "value" to an individual. Is there anything to make sure that what they interacted with can not completely broken by the other site of the party?

And it seams to not be the case on the stable compiler version?

  fn write(x: &mut i32) {*x = 10}
  
  fn main() {
      let x = &mut 0;
      let y = x as *mut i32;
      //write(x); // this should use the mention implicit twophase borrow
      *x = 10; // this should not and therefore be rejected by the compiler
      unsafe {*y = 15 };
  }

So one better makes sure that it has not the potential to further introduce gatekeepers, where later such gatekeepers will realize that, in order to continue to live, they need to make a profit over everything else, and then everything is out of the window.

The ferroscene language spec was recently donated to the rust foundation.

[1] https://doc.rust-lang.org/reference/behavior-considered-unde... [2] https://spec.ferrocene.dev/undefined-behavior.html

[1] https://en.wikipedia.org/wiki/LiMux

While the outcome is quite unfortunate, the way they provide all info here seams like a plus in my book here.

If a state/entity comes after your org tomorrow, and you got to either fight legally or leave the market (like cisco in the story), what would you do?

https://tailscale.com/blog/how-nat-traversal-works

So that is at best a incomplete picture, and at worst a specific framing of a particular view.

I am neither endorsing nor rejecting what is happening (i am not American), just want to point this out here.

Using this flag one than can use `panic_abort`. This will eliminate the unwinding part but would still give a "nice" printout on a panic itself. This reduces, in most cases, the mention bloat by a lot. Though nice printouts also cost binary space. For eliminating that `panic_immidiate_abort` exists.

But yeah the above is only about bloat and not the core goal to eliminate potential path's in your program, that would lead to a panic condition itself.

Also currently building the std library yourself needs a nightly compiler. There is afaik work on bringing this to a stable compiler but how exactly is still work in progress.