Did you know, there are examples of multiple bitmap districts inscribed on the same sat?
This is because there was never a condition specifying that the sat should be unique, and it's what indexers have been running with since.
Automated inscribers sometimes use the same sat for multiple attempts to inscribe a bitmap, and this leads to them getting multiple, but on the same sat.
It's an interesting edge case, as it means these districts are intrinsically linked and cannot be separated. If you send one, you send them all.
If I were to design bitmap again from scratch today, I would make sure it can't be on an existing Bitmap sat, however I can't do that so it is what it is.
However, it leads to an edge case in signal theory, which I've had to come to terms with.
If you signal from one of these bitmap sats, one signal may amount to multiple, based on how many districts are on the sat.
The obvious problem is that you might want to signal independently from each district, not one signal for multiple districts.
This could be a little more problematic for districts that span multiple hoods, where the district signalled is outside the range of the district you are signalling.
We have to go with it for now. It's the way the cookie crumbles.
I cannot make changes to a consensus that holds so much weight by myself.
However, one path is that we can raise this question as one of the first democratic issues of bitmap.
It is possible that we can fix this edge case. It will not be too difficult to do this for all future districts from the point the decision is made. However, doing this retroactively will invalidate some districts, and validate other previously invalid ones.
This will fix the issue where one send of a bitmap is actually a send of multiples, so the benefits of making this change may outweigh the drawbacks.
The realistic case is that we index both realities, and let consensus emerge from indexer and product adoption.
But I think we can also raise it as a referendum type situation within the signal, so we can see what version of Bitmap the community would rather see.
It could become the first real test of our ability to collectively make decisions on serious issues that may affect Bitmappers and the integrity of the standard, but also, the first time Bitmappers get to decide individually which version is the one they support.
The first true bitmap fork!
Ultimately, products that run bitmap indexers (marketplaces, Metaverses) will have to choose one version, and currently the default indexing is that multiple bitmaps on sats are okay.
Note. Things will stay the same for 99.99% of the bitmap index.
I'll leave this here for now, but I wanted to start the conversation now, so you are all aware of the situation, and maybe soon after the signal starts, we will raise the issue in a town hall space and move towards inscribed proposals or acts for people to signal one way or the other.