Scientists frequently speculates using Brain in a vat experiment. Many of us know it as the Matrix. Is it really possible?

Definitely yes:

1. In 1992 The Lawnmower Man moview was very fantastic. Nowadays virtual reality environment is as simple as smartphone with a VR gadget. Progress never stops, so sooner or later we will have such gadgets that will interface directly with our brain.
2. It's easy to explain that this is theoretically possible. Did you ever have realistic dreams? Many of us did. But all movements, sounds and pictures are just a result of our brain. They were not real.

Everybody who is familiar with good principles of software design (e.g. SOLID) knows that it is much better to depends on abstractions, not concretions. But what I have seen in this project is a "Fragile Web". You MUST have a WebID that MUST be an HTTP URI that MUST be in text/turtle format that MUST be RDF and MUST use FOAF for person attributions.

For example, we have a good old abstraction - URI. It works good when implemented as a WebID. But supports a lot of others as well. Just imagine that in a close feature mankind decides to put personal data in a distributed ledger like Bitcoin and will be addressed like its wallets, for instance "bitego:1EgoSL8HtK4ngkdXEeobR76b53LETtpyT". This is still a good URI, but not a WebID. May be personal data will be powered by InterPlanetary File System and URLs like ipfs://stan.ego or Magnet URIs or web becomes real-time and ws://stan.ego will be actively used. There can be a plenty of implementation for one good abstraction... and this is definitely not WebID.

Why should we limited by RDF only that from 2004 can't prove itself as a good instrument for semantic markup? Old MIME types and headers like Accept-* can be easily used to manage any implementations based in client-server negotiations.

REST API? Are you kidding? So many efforts like RDF towards semantic Web and instead of good abstractions like GraphQL or SparQL we are going to use REST API? REST that tries to break the beauty of resource location (URL) by adding a lot of garbage to it?

I completely did not notice how Sir Bernes-Lee going to implement his own brilliant ideas about editable (wiki) Web.

In my opinion solution is pretty straightforward.

There is a good abstraction called DVCS that helps a lot of people to work on content in distributed manner. We know its implementations - Git. You want to edit any site? Fork it, make changes and create a pull request. There is even a good old protocol for content authoring in such manner called WebDAV (Web Distributed Authoring and Versioning).

For user authentication in Solid applications, instead of WebID and other RDF-based stuff, URI is enough. I will be able to be identified by domain I have purchased like http://stanego.com, by my Bitcoin wallet URI, Magnet URI, By phone number that also have URI like tel:123456789.

Instead of being forced to use RDF I want to have conversation between client and server, which semantic protocol they want to use. Client can send "Accept-Semantic: rdf/turtle, xml/xsd, something/new" and receive "Content-Type: something/new" as a result of their agreement.

Last days I was actively writing about aspect-oriented approaches that seems to be such balance. Each database record has a lot of aspect in it. For instance "users" table frequently contains lifetime aspect (createdAt, deletedAt, etc), authentication  (login, password, blocked), person (firstName, lastName), address (country, city, etc), many payment aspects (because many types of payments), etc.

Storing each aspect, not an each field in a vertical partition, like columnar databases  do, looks to be a good balance. We usually work with entities in scope of some aspect. E.g. when you're authenticating an user, you don't need its address. Making a payment doesn't involve it's authentication details, etc.

So when we are authenticating, we use the only vertical partition responsible for this aspect. And as a result - minimum of IO operations (works only with required subset of columns).

It will be encoded and stored as effective as columnar databases but with less overhead. And mostly beat row-based engines. For example ones those support clustered indexes will be able to have more that one per virtual table because physically one clustered index will be allowed for the each aspect-partition.

I think there are. One of the most frequent examples is interface IEntity<T> with property Id of type T. It says that object is uniquely identified in the persistent storage. Sometimes we are talking about parent-child relationship, which can be realized as a IChild<T> interface with Parent property of T type. Many entities have names. So IHasNamed aspect can be frequently used. IActive aspect with enabled or disabled status. For logistics you may want IDimensions aspect, IValuable for e-commerce, etc.

Idea is that we consider object as a set of aspects with possibility to add them dynamically. Just imagine that you have a IMembership interface provided by some security frameowkr that you can't upgrade. But want to make membership expirable sometimes. E.g. one of your admins is on vacation and you are going to grant this role temporarily to another employee. For that purposes you've created ILifetime interface with Start/Expiration properties and create new membership like _factory.Entity<IMembership, ILifetime>();

Many other benefits are inherited from https://stanego.com/business-objects-redesigned/.

Philosophically let's imagine we are talking about some laptop. What is usually important for us? Probably it's technical specs. Especially when we're going to buy it. Tomorrow we have a flight and more important aspect of the laptop will be it's size and weight while we're packing it into our luggage. If you looking for something to hammer a nail the laptop will appear from the different point of view. So any object may have different aspects. And these aspect are interfaces.

Let's take a look briefly into advantages.

Firstly, you can't inject logic into schema that is not a good approach because highly couples responsibilities. For example, let's consider validation. When you're buying the laptop, you have specs-based validation. When going to flight, size/weight-based validation. So validation is process external to the object itself, made by subject and environment.

Secondly, even if you need some logic, it can be automatically or manually added to the implementation of this interface. And here you'll have a kind of AOP (Aspect Oriented Programming) where any aspects can be flexibly added to the objects.

Thirdly, designed based on interfaces is always more flexible. You'll start to extract different aspects of your classes, because won't be limited by "inheritance hell" and can easily build mixes from different interfaces to craft new view-models, DTO models (requests, responses), etc.

Simple example. Many objects have Name property. Event if they are very different and you can't provide the property by inheritance. This is a specific aspect of "named" things. Or some "hierarchy" aspect that defines Parent property.

A good solution is to define it in IHasName interface. For this interface you can define validation rule, that will be automatically injected into property setter when your IoC will create an instance with this interface.

This approach has many benefits. For example, one of them I temporarily called "locking". Changes to the smaller systems cause less locking than to a huge one. For example, deployment of micro-service cause less availability problems than deployment of the huge monolithic application. Unexpected requirement for an agile workflow is much easier to integrate than for waterfall.

Another one is "distribution". If you split system into N subsystems then you can employ N workers to handle them. For distributed computing systems this is obvious, but such principle also makes agile project management highly collaborative.

I feel me like reinventing a wheel and wonder if this idea is already described somewhere with all pros and cons.

Let's imagine that there is an intellectual compression algorithm that works like LZ compression, replacing some code with reference. For instance, quick-sort implementation in any language is replaced with reference to some standard implementation. Some frequently repeatable patterns with DSL constructions.

I wonder if GitHub can be stored on the MicroSD card then :)

P.S. STEPS project by Alan Kay, with very high degree of reusability, has TCP stack implementation just in ~200 LOC.

Accordingly to Wikipedia issue is a "unit of work to accomplish an improvement in a system". That is... change. And this term is more flexible. For example we can consider potential change (risk).

We can then review typical Backlog-In Progress-QA-Deliver workflow of agile methods and even Red-Green-Refactor approach in TDD through a more mature Plan-Do-Check-Act in change management.