IGNITION!
6ae8f23655a19588ebb025af759670cffe2543f4c21b6576f27ceb43bc6873fa

The Times 23/Jun/2023 Mortgage misery for millions.


I'm requesting to join the Nostrocket Identity Tree and claiming my permanym: hodlbod


I'm requesting 10000 sats for resolving problem d542e4e6ebdf31d9a22d8c87886051c79e153e86b9ebf77b056008d4502609d6 in rocket 041b8698b3b7206feca17c89f3f861c31d82dc2fdf3f1d0f25c3bddfa68c64e2


This is cool..


I'm requesting 38226 sats for resolving problem 528c3273844fe44152936a67d11737097dcfd40817e2775c0294fe3cf2bcac54 in rocket 5ae2d0f32aa7f656a752cb1700c175fb8e37132effdcf1836c019322d4dd31af


I'm launching a new Rocket to resolve problem 8dcd6974f1dc5da2deeb3e20ec7e9229d812ab60ed00dc99d8ce78468497c474. I'm calling this rocket: cyberspace!


[Problem: many unrelated comments are displayed on problems] on the nostrocket problem tracker was previously closed but I'm re-opening it because it appears that it isn't resolved.


I'm claiming [Problem: There is no permissionless, decentralized digital space protocol] on the nostrocket problem tracker so that I can work on it and other people don't duplicate my efforts.


Problem: we are not living up to our full potential as humanity

This initial problem is intended to set the scope of all possible problems that MAY become applicable to Nostrocket - in the broadest possible sense.


Problem: Bitcoin is not fixing the world fast enough

We have all the tools we need to create a golden age for humanity, but we aren't using them in the most intelligent possible way.

Bitcoin has created a new territory of freedom by providing a form of Money that operates in parallel to legacy civilisation, but Number Go Up technology has created a tenacious complacency: get in the lifeboat or put the oxygen mask on, and Satoshi (MHEP) will do all the work. It's careless to assume that a universal Bitcoin standard is inevitable.

We are likely approaching two challenges on the path towards a universal Bitcoin standard:
* The Fiat Dominion is slowly overcoming its arrogance and waking up to the existential threat that Bitcoin poses. We can hope for the best, but it's naive to believe the Fiat Dominion will not use every class of weapon at its disposal as it fights for survival.
* Civilisations tend to collapse exponentially in a cascade failure. The loss of trust in key institutions is a clear signal that this process is underway, and we are likely to be much closer to chaos than it appears to our linear-thinking minds. If Bitcoin doesn't fix things before this happens, we will need to do things the old fashioned way, which sounds romantic but it isn't fun for anyone.

### Solution: a self-organising civilisation centered upon Bitcoin

The simplest solution is not to fix the current structures and system(s), but to instead build something new, in parallel and as an opt-in alternative. If successful, it will become a fallback position for the masses as legacy civilisation continues its collapse.

The flow of humanity into a Bitcoin standard is dependent upon the community around Bitcoin making Bitcoin more useful - the larger the economy *around* Bitcoin becomes, the more useful Bitcoin itself is and the faster humanity transitions to a Bitcoin standard.

A civilisation that's centered on Bitcoin will naturally accelerate the usefulness of Bitcoin (to the degree that the civilisation itself is useful). In this regard, our parallel civilisation is just another tool in Bitcoin's toolbox. Instead of trying to modify Bitcoin to become a sharper instrument, we create resilient and powerful parallel systems that integrate Bitcoin.

Nostrocket, or any similar attempt, would not be possible without Bitcoin, as anyone who's ever uttered **fix the money fix the world** will understand. Here are some examples:

* A free and open civilisation requires honest price discovery, which can only happen with sound money.
* A civilisation based on a Money that can be created at no cost is ultimately a worthless civilisation.
* Nostrocket needs a source of undeniable and objective **Newtonian** truth that everyone can agree on:
    * A shared clock to know when things happened in the past, what's happening right now, and roughly how long till things should happen in the future.
    * Objective certainty that some information existed at a specific time in the past.
    * Objective certainty over the current financial state of a system/organisation/person/transaction/etc.
    * A constant of economics such that we have the ability to objectively reason about our civilisation's economy.
* Nostrocket requires economic value to be transacted between parties even when powerful interests want to censor these transactions.
* Nostrocket requires some mechanism by which state can be considered immutable.
* We need to know (in a way that leaves no doubt) when something doesn't work and let our new civilisation's ideas die instead of the civilisation itself. Bitcoin is a source of Darwinian truth, and can act as guard rails against Darwinian mistakes - does x produce surplus or not?

Aside from a Bitcoin standard being the only viable mechanism to keep any civilisation sane, the corollary to the dependency on Bitcoin described above is that Nostrocket needs Bitcoin to live up to its full potential, so Nostrocket should naturally:
* support the ongoing development and adoption of Bitcoin, maximising the degree to which Bitcoin benefits humanity,
* ensure that Bitcoin benefits the bottom of the Cantillion pyramid more than the top
    * ensure that the bottom of the Cantillion pyramid has the greatest trust in Bitcoin
        * ensure that the bottom of the Cantillion pyramid is the most Bitcoin-literate
    * ensure that those at the bottom of the Cantillion Pyramid have the most frictionless and lossless access to store their economic power in Bitcoin
* prevent any changes to Bitcoin that reduce the degree to which Bitcoin is resistant to attack by the Fiat Dominion
* be capable of rapidly addressing any imminent threats to Bitcoin, for example if there's evidence of a capability to break any of the cryptographic primitives
* uphold and promote a view of Bitcoin not as a complacency-breeding NGI technology, but as an active guerrilla insurrection against fiat occupation


Problem: we don't have a good way to focus the action of multiple humans while remaining sovereign

When Bitcoiners organise around shared goals, they tend to rely on the State to anchor their organisational structures and serve as the mediator of last resort between all stakeholders. Coinkite, for example.

All human organisational structures are fundamentally composed of human action (and **inter** action) because human action is the **only** primitive by which humanity can influence how the present reality is brought forth from the infinite potential of the future.

Families, tribes, companies, governments, civilisations, etc are all examples of organisational structures composed of human action.

#### Composing human action through boundary conditions

The usefulness of a bucket is created by the limitations or restrictions imposed by its base and sides. A bucket is useful because it holds water by creating **boundary conditions** on what the water **cannot** do while **remaining in the bucket**.

Human organisational structures are useful because what they do with humans is analogous to what a bucket does with water. These structures are defined by their boundary conditions on human action - what type of action humans can take while remaining within the organisational structure.

**Centrally planned** organisations like companies or governments tend to create boundary conditions on human action through a combination of:

* internal rules about what types of human action is permissible,
* internal rulers with the power to decide when to change the rules, and when to break them, and
* excluding people who don't submit to the rules and rulers ("don't fit the culture" or aren't a "team player").

Human action within organisations is also restricted by the underlying security model. Investors tend to rely on the State to enforce contracts, and so any organisation that wants to raise money tends to be nested under the State. All humans within such an organisation are therefor ultimately responsible to the State for their actions. For example, the CFO is responsible to the State for all financial activity performed within the organisation, and all humans within the organisation are responsible to the CFO when their action involves money. The same is true for all aspects of the organisation. It's therefor impossible for an organisation to be nested under the State without being centrally planned.

Centrally planned organisations exist along a spectrum of just how centrally planned they are - from highly planned military organisations to the **Teal** organisations as described by Frederic Laloux (well worth skimming through his book).

So-called **Decentralised organisations** tend to restrict human action by:
* deciding ahead of time on all the possible types of human action that shall be permissible within the organisation, and
* encoding the rules about these actions into some form of state machine (usually a "smart" "contract").

These organisations are typically inflexible due to this architecture. Modifying the set of human action that is permissible within the organisation requires smart contracts to be republished, which is where the community generally falls back to trusting a central team.

#### Mutexless organisations

The more you need upfront consensus or agreement on what to do, the [less speedup you get](https://en.wikipedia.org/wiki/Amdahl%27s_law) by adding additional "workers".

The more sequential operations or mutexes you have, the less speedup you get by adding additional threads or workers because all of those threads need to pause execution and wait for the sequential parts of the process. It's a non-linear relationship: a tiny increase in wait-states drastically reduces the speedup gained when adding more threads. At some point, adding more threads does not result in any speedup.

In human organizations, we have the same thing. Individuals within the organization are workers or threads. Human organizations have a ratio of sequential to parallel operations, just like computer programs. The more a team needs to stop and synchronize, the less work they get done and the smaller the maximum team size, after which adding more people does not result in any additional productivity.

Requiring permission or agreement over what to do within an organisation is a sequential operation. Meetings are the mutexes of human organisations.

Thus, the most efficient organisational structure is one where participants can do productive work without requiring any permission or agreement with others over what work to do.

#### Sovereign organisations

Sovereign human action is human action taken by a **sovereign individual**.

Sovereign human action does not **require** permission from others. It does not **require** upfront consensus or agreement. The sovereign individual MAY seek agreement or permission before taking some action, but this is not **required**, it's entirely their own decision.

A sovereign organisation is one where individuals may participate while remaining sovereign. A better term for this is a sovereign unorganisation.

The organisational structure of a sovereign unorganisation MUST be composed of sovereign human action.

A sovereign civilisation is probably some form of meta sovereign unorganisation composed not only of sovereign human action but also many sovereign unorganisations, and inhabited by sovereign individuals.

#### How do we focus sovereign human action?

If an organisation is sovereign, it's also mutexless because participants can do productive work without requiring any permission or agreement with others over what work to do.

The implication is that participants within such an organisation can do work without anyone knowing what they are working on, because work can be done without any upfront agreement on what is being built.

How do we create an organisational structure which allows individuals to remain sovereign and work towards building something without requiring any agreement on what we are building?

What are the boundary conditions on sovereign human action that create the conditions for such an organisational paradigm?

The metric we use to judge if Nostrocket has optimal boundary conditions on human action within it is the community size - are humans being attracted to it faster than any alternative?

* Humans with something to contribute must be better off by acting **within** the structure of Nostrocket than they are by acting within any other structure.
    * Nostrocket must result in more value for Participants than any other opportunity available to them.
    * Nostrocket must become, and actively remain, the most efficient organisational paradigm possible with the current technology
        * The mechanism by which work gets done within Nostrocket cannot require upfront agreement on what that work should involve or what the end result should look like
        * Nostrocket cannot require any upfront funding and cannot retain any capital
    * To remove any internal friction, Nostrocket must be radically fair to all Participants, more fair than any other organisational structure
        * Nostrocket's rules and ideology must be as pristine and *credibly neutral* as possible
        * It's not possible to be as pristine and neutral as Bitcoin because Nostrocket is an organisational structure while Bitcoin is property, but Bitcoin is the standard to judge against.
    * The boundary conditions or limitations should be simple, explicit, clear, and graduated such that there's no overhead required to onboard new Participants, and Participants may advance at their own speed along their own zone of proximal development.

---

### Possible Solution: an unprotocol for a universally applicable hill-climbing algorithm, executed by sovereign human action.

The core of the solution is a hill-climbing algorithm which optimises for increasing the number of Participants.

Software can be used to make things more efficient and to provide continuity of the current state of Nostrocket, but the algorithm itself is executed by self-interested sovereign human action and not machine.

Human action within Nostrocket must be executed for purely self-interested reasons in order for it to be optimally efficient, accurate, scalable, and to minimise any social attack surface. When people solve problems for their own reasons, the solutions are more accurate than when they are doing it because someone is coercing them with money. A case in point: organic contributions to wikipedia vs. paid contributions.

The life-force (or fuel) of an organisational structure is human action that yields **surplus** - that means production of surplus is in the critical path to more Participants, and so our algorithm must optimise for this.

Amdahl's law can be restated as "the more you need consensus about what to build, the less efficient you will be at building it". For Nostrocket to be the most efficient problem solver and builder, it must require the least amount of consensus on what to build and how to build it.

Projects like ZeroMQ have proven that it's possible for valuable products/services (i.e. powerful and effective solutions) to evolve from simple rules with **no upfront planning** or consensus. This is core to our approach to innovation and surplus without requiring any consensus on what to build or how to build it - no upfront planning and no leadership.

The set of boundary conditions for human action within Nostrocket is defined by the Nostrocket Unprotocol. It's rather long, so here's a summary:

0. Anyone who's not already a **Participant** MAY become a Participant by being validated by an existing Participant. This results in a **tree of Participants** called the Identity Tree.

1. Change follows the **Serbian method** - a continuous pattern of accurately identifying **Problems**, and applying the **simplest possible solution** to each Problem.
    * This project is currently applicable only to a *very* tiny subset of humanity who are able to understand the concept and do something useful with it, but this subset should get *less tiny* with each problem solved.
    * As these problems and minimal solutions pile on top of each other, novel and valuable products/services will evolve (read the protocol to get a more complete picture of how this works).
    * There's nothing that inherently limits Nostrocket to producing software based solutions, it could also produce hardware, houses, food, etc.

2. Any Participant MAY log a **Problem** (an observed matter or situation regarded as unsatisfactory).
    * There are no bug reports or feature requests, these are just problems (or they aren't).
    * There are no priority levels for problems, there are just problems that are worth solving (or not).
    * Problems should be reasoned about and broken down into smaller problems until they are objective or replicable, and actionable.
    * Problems should be broken down until they are small enough that they can be solved very quickly - anything longer than 6 hours of working time is probably too big.
    * Problems MUST be relevant to Nostrocket itself. Nostrocket is not a freelancing market or a problem-solver for hire.
    * Problems MUST be nested under another Problem, creating a Problem Tree.

3. Any Participant MAY **Claim** (and solve, typically with a **Patch**) any unclaimed Problem. Any **Maintainer** can (and should) **Merge** any Patch that does **not** violate the Unprotocol.
    * At this early stage most of the problems Nostrocket is likely to encounter will simply be with its own implementation, hence they will typically be solved with a Patch. However, if the experiment is a success this will start to involve the physical world, things like Nostrocket meetup or conference related problems might be some of the first examples.

4. A Participant who solves a Problem MAY indicate the value of their work by creating a **Merit Request**
    * A Merit Request MUST be denominated in Satoshi
    * A Merit Request is **not** an entitlement or guarantee to be paid
    * An Merit Request is how a Participant SHOULD communicate the sacrifice they have made in solving the problem
    * An Merit Request allows Participants to peer review the value being claimed by comparing individual solutions and their associated Merit Requests

5. Participants with **Votepower** MAY vote to **Ratify** (approve) or **Blackball** (reject) a Merit Request.
    * The Merit Request SHOULD be rejected unless it's along the route (or **critical path**) to more Participants.
    * Votepower is a measure of a Participant's **skin in the game**.
    * `Votepower = Merits * Leadtime`
        * Every Participant's `Leadtime` starts at `0`.
        * A Participant's Merits **cannot** be spent/transferred if their `Leadtime > 0`.
        * A Participant MAY increase or decrease their Leadtime by `1` every 2,016 blocks (but can't become negative)
        * If more than 50% of Nostrocket's Votepower approves a Merit Request, and less than 5% reject it, its Approved.
    * If Participants with Votepower reject Merit Requests that comply with the Unprotocol and are reasonable amounts, others will see this and stop working, and Nostrocket will die or be forked.
    * If Participants with Votepower approve Merit Requests that should not be approved, they are diluting their own Merits for no good reason.

6. If a Merit Request is **Approved**, new **Merits** are created for the Participant who logged the Merit Request (1:1 per Satoshi claimed in the Merit Request).
    * Merits MUST NOT be created **any other way** (that would mean the experiment has **failed**).
    * Nostrocket has been instantiated with a **single** share as this is technically the only way to bootstrap the process.

7. Participants own **all** revenue produced by anything Nostrocket builds. Whenever anyone pays for a product/service created (or **discovered**) by Nostrocket, the Sats are streamed **directly** to Participants in proportion to the number of Merits they have and how long they've had them.
    * Revenue distribution MUST be fair for everyone. Potential Participants who take more risk by making sacrifices before it's clear if the experiment will work or not need to agree that it's fair. Potential Participants who want to do work after the concept is well established and revenue is being generated must also agree that revenue distribution is fair.
    * When there's a pot of money available, Mallory finds a way to corrupt whatever is guarding it.
    * Nostrocket MUST NOT retain any capital or raise any funds (and doing so is an anti-pattern that fundamentally precludes decentralisation).


Problem: nostrocket is not currently applicable to more than a few people

The nostrocket implementation is currently lacking most of the features that are described in the unprotocol and thus it is only applicable to people who can implement this.

The nostrocket implementation is currently lacking most of the features that are described in the unprotocol.

This means most people are not really able to use nostrocket. It's only really applicable to a few people at this stage because it takes a lot of time and effort to understand what it is and even more to get involved.

Solution: start adding problems nested under this one when it relates to the implementation and UX of OXYGEN.

Whenever logging a problem, think: does solving this problem bring Nostrocket a step closer to the next Participant getting involved?


Problem: Identities are sometimes in the wrong order

When adding someone to the Identity Tree, they sometimes appear in the wrong order.


Problem: multiple people can work on the same problem at the same time, duplicating the work done.

Duplicated effort is evil. Doing work to solve a problem that someone else is already working on should be done at the Participant's own risk, but at the moment there's no indication of this risk (a lack of informed consent).

The Nostrocket unprotocol calls for Problems to be "locked" or "claimed" when they are being worked on, such other other Participants are aware of this and don't duplicate the efforts.


Problem: Identity Tree is slow to populate

The Identity Tree (under "People") is slow to populate because it doesn't render anything until it has fetched the full profile and avatar of each Participant.


Problem: problem logging form doesn't reset after successfully logging a new problem

The text entered into the problem logging form doesn't reset after submitting the form and successfully publishing the event. When opening the form to log a new problem, the content of the previously logged problem is still there.


Problems can be created, but not modified.

Solution: patch `LogNewProblemModal.svelte` such that existing problems can be modified.

Populate the new event data with the latest known `kind 1971` problem and publish a new one with the desired changes.


At the moment, problems can only be logged but cannot be commented on or discussed.


Problem: the way we fetch single events is retarded

The way we currently fetch single events is retarded because we do a whole new subscription etc, this can be seen in how `routes/eventviewer/[id]` calls `livesubscriptions.ts`.

Solution: use NDK's `fetchEvent` thing.


Maintainers can do things like edit problems. The list of maintainers exists as another Identity Tree.

Solution: add maintainers to Identity Tree NIP
Implement adding maintainers in Oxygen.


Problem: can't re-use problem tracker event destructuring code

The way we handle problem tracker events is to destructure them into the Nostrocket state, this means that we need to put previous problem events into state to be able to view them.

What we should do instead is destructure Problem Tracker Events (`kind 1971`) on the fly when needed.

For example, instead of querying the current Nostocket state to find a problem's parents, we should read this directly from the tags in the event.


Arkinox tried to create a new Rocket but it doesn't work.


Wanted to tag Arkinox in a problem that he told me about, but I can't easily do that.


Problem: not clear to user when their event is pending consensus

When a hard state change event is created it does not enter the current state unless someone with votepower in that state appends it to their consensus chain. This is very confusing to the user and it looks like it isn't working.


Problem: can't test state chainge requests without modifying current state

We currently have no way to test state change request validity against the current state without modifying the current state.

We need to be able to do this so that we can produce consensus events without modifying the current state.


Rockets can be created but not deleted. I want to delete a rocket that I created by accident, but I can't.


Problem: deleting a state change request event after it's in consensus everything breaks everything

If a user deletes their state change request (with a kind 5), and that event is already in our consensus chain, the chain breaks.

Solution: embedd the entire event inside consensus events.


Problem: /problem/[id] route doesn't work on refresh

/problem/[id] route doesn't work on refresh, so we can't send people links to problems


It's basically impossible to debug certain types of problems because there are no debug symbols. Can't find what the error is actually referring to.

For example:
!(error)[https://image.nostr.build/94c7040f6cbc9aca19c30385a7cf548b62ed4c48369f8749a9ba2eb26d4f4e06.png]


Problem: images are not displayed in problem tracker

When including a markdown image in a Problem, the raw URL etc is displayed rather than rendering the image itself.


It's basically impossible to debug certain types of problems because there are no debug symbols. Can't find what the error is actually referring to.

For example: ![error](https://image.nostr.build/94c7040f6cbc9aca19c30385a7cf548b62ed4c48369f8749a9ba2eb26d4f4e06.png)


Problem: can't associate an existing Rocket with a Problem

Rockets can own branches of the Problem tree by default, but this isn't implemented.


Problem: can log a sub problem on a problem that is not open

A problem that is claimed, patched, or closed cannot have sub-problems, but it's currently possible to create them.


Arknox wants to use Nostrocket but some critical features are preventing him from doing this.


Problem: some problems are blocking multiple parents but this can't be reflected in the problem tree

There are many problems that I've logged which are applicable/blocking the Arkinox problem, but I can't move/add them as children on this problem.


At the moment, problems can only be logged but cannot be commented on or discussed.

It's important to be able to discuss problems that are logged here. We can't currently do this.

Solution:

Implement comments.

These should be `kind 1` so that they can be read by any client. Everything should just be done the normal nostr way.

They should use an `e` tag pointing to the Problem event ID (available in the problem object as `problem.UID`) , and this should use the `root` marker.

For threaded replies, an `e` tag pointing to the parent comment, with the `reply` marker.

I suppose the comments and a reply box should just be displayed below the problem or something.


Problem: when adding someone to identity tree UI incorrectly reports they already exists

This doesn't stop it working, the form can still be submitted, but it's confusing.


Problem: valid rocket ignition events are being rejected

valid rocket ignition events in the consensus chain are being rejected due to a failure to verify inclusion in the identity tree


Problem: can't view all problems associated with Yondar

I want to be able to see all the problems associated with a given Rocket (e.g. Yondar). This is not currently possible.


Problem: can't tag problems with a Rocket

We can't currently tag problems with a Rocket.

Solution: allow any Maintainer on a Rocket to tag any problem with that Rocket.

Sub-problems underneath that should be automatically tagged.


Problem: can't claim merits for work done

After a patch has been merged, the contributor should be able to submit a claim for merits.


Problem: can't easily see which problems I have claimed etc

I want to be able to see which problems I've claimed, solved, logged, etc.


Problem: comments on problems don't show immediately

When commenting on a problem it doesn't immediately show, it only shows after page reload.

This is because of the way that comments are subscribed to. Instead, we should create a global comments store, and add a new subscription for each problem ID.


Problem: problem events don't show in existing nostr clients

When we comment on problems, existing nostr clients just show this as a reply to nothing.

Solution: use NIP-89


Problem: some problems are blocking multiple parents but this can't be reflected in the problem tree

There are many problems that I've logged which are applicable/blocking the Arkinox problem, but I can't move/add them as children on this problem.

The solution would need to offer users a way to add these, but with the following requirements:

* MUST NOT be able to add children that already exist on this branch of the problem tree (children of children...)
* MUST NOT create circular dependencies, cannot add any of this problem's parents or their parents.
* The user taking this action MUST be a maintainer on any rockets that this problem is tagged with


Problem: actions on problems sometimes get repeated

For example, problems become claimed again after abandoning them.

Solution: validate that this event has not already been handled, and that it is newer than the last handled event.


sherry's test problem to make sure everything is not broken

this is a test problem and it should not get in to consensus chain

This is a nostrocket-problem event. Check it at nostrocket.org


Problem: can't filter problems by rocket

I want to be able to filter problems by rocket but I can't


Problem: errors while logging problems are not returned to the UI

Errors are printed in the console, but they are not indicated to the user.

Solution: use a toast or something on errors


Problem: we are not publishing to user's relays

When people comment on a problem, we are not publishing the event to their relays

Solution: find out how this works with NDK or if we have to do it manually.

Also publish the problem they are replying to.


When people comment on a problem, we are not publishing the event to their relays, we are only publishing it to the relays hardcoded in the Oxygen client


When people comment on a problem, we are not publishing the event to their relays, we are only publishing it to the relays hardcoded in the Oxygen client.

Solution: find out how this works with NDK or if we have to do it manually by checking their relay set etc

Also publish the problem they are replying to.


Problem: can't see edit history of problems

I want to see the edit history of a problem but I can't, e.g. within the comments section I should also be able to see when a problem was modified, when it was claimed/abandoned/patched/closed/re-opened/etc.


Problem: difficult to focus on just the problem tracker problems

I'm noticing a lot of annoyances when I use the problem tracker and have been logging them to keep track, but having all these problems in a long list with all the other unrelated problems makes them difficult to focus on.

Difficult to say which is simpler: putting them all  as children under a single "problem tracker" problem, or tagging them as problem tracker.


Problem: some problems are blocking multiple parents but this can't be reflected in the problem tree

There are many problems that I've logged which are applicable/blocking the Arkinox problem, but I can't move/add them as children on this problem.

The solution would need to offer users a way to add these, but with the following requirements:

* MUST NOT be able to add children that already exist on this branch of the problem tree (children of children...)
* MUST NOT create circular dependencies, cannot add any of this problem's parents or their parents.
* The user taking this action MUST be a maintainer on any rockets that this problem is tagged with

Solution:
Allow maintainers to drag/drop problems to re-organize them, and allow them to drag/drop while holding a specific key so that it "copies" to a new parent instead of moves.


I'm noticing a lot of annoyances when I use the problem tracker and have been logging them to keep track, but having all these problems in a long list with all the other unrelated problems makes them difficult to focus on.

Difficult to say which is simpler: putting them all  as children under a single "problem tracker" problem, or tagging them as problem tracker.

For now, I'll just log them all as children under this one.


Problem: markdown on problem detail route doesn't look as good as it could

Line breaks don't seem to be show all the time, etc.


Problem: workflow for logging a problem isn't clear

It's difficult for a new user to figure out how they should log a problem and what they should write.

Solution: use a step by step thing to guide the user into logging a new problem.

Present each field on its own so they can focus on just that.

Give them examples of good/bad problem statements?


Just noticed that one of the problems I thought was solved is not, so I want to re-open it, but I can't.


There are many problems that I've logged which are applicable/blocking the Arkinox problem, but I can't move/add them as children on this problem.

The solution would need to offer users a way to add these, but with the following requirements:

* MUST NOT be able to add children that already exist on this branch of the problem tree (children of children...)
* MUST NOT create circular dependencies, cannot add any of this problem's parents or their parents.
* The user taking this action MUST be a maintainer on any rockets that this problem is tagged with

Solution:
Allow maintainers to drag/drop problems to re-organize them, and allow them to drag/drop while holding a specific key so that it "copies" to a new parent instead of moves.

Problem: sometimes there are a lot of problems I want to move or copy. Solution: Add a checkbox to the list of problems to move them on mass.


Problem: can't find problems that I know exist

I was trying to find a particular problem, but using the filter didn't reveal it becuse the problem was closed.

Solution: by default, set the problem status to "all" when user starts typing in the filter. But if they set the filter status after this, apply it.


Problem: workflow for solving a problem isn't clear

The workflow that a user goes through when solving a problem is not self-evident.

Guide the user through the process of claiming a problem, sending a PR, marking the problem as waiting for validation


Problem: can't add git repo to a problem

When user is told how to solve a problem they need to know where the git repo is for whatever project this problem applies to


Problem: contributors don't know how long they have to solve a problem

When claiming a problem, contributors need to either send a PR within 432 blocks, or request an extension from a maintainer. This is not clear in the UI.

Solution: show time remaining, and show a button to ask for an extension (which just prefills a comment and tags all the maintainers).


Problem: contributors don't know the rules about sending a PR

There are rules about sending PRs and what they need to include. This is not clear to the contributor.

Solution: tell the contributor that

1. The PR MUST contain a SINGLE commit
2. The commit (and PR) MUST contain the same tl;dr as the problem statement in the problem tracker
3. The commit MUST be their best attempt at the simplest possible solution (in terms of code simplicity, and UX simplicity)
4. The commit MUST NOT break any tests if they are defined
5. The commit MUST NOT break any existing functionality or cause a regression
6. The commit MUST NOT make the UX more difficult to use
7. The commit MUST follow code style guidelines if these are defined on the Rocket


Problem: humanity's social graph is vulnerable to MITM attacks by government and big tech

Government and big tech mediate our social graph. This is a MITM attack against the collective sensemaking capacity of sovereign individuals.

Governments and big tech have been attacking humanity's online social graph and intervening in our relationships to influence how we communicate and and how we think.

Technically, we have a solution to this: nostr. But not everyone is using it, and not in all domains under which social graphs operate.

This problem is intended to be a catch-all for anything in the critical path towards humanity using nostr as its primary social graph for all collective sensemaking.


Problem: not sure if rockets can select a problem

This is a problem to test if rockets can select a problem or not


Problem: sidebar is not optimized for most common action

The sidebar uses a menu for some actions. This should be used for the least common actions. The most common actions should be directly accessible.

Solution:

The next lifecycle action button should always be visible. E.g. for open problems without children the Claim button should always be directly visible.

If in progress and current user is the one who claimed it, the "patched" button should be visible.

If "patched", and current user is the one who logged the problem, the close button should be visible.


Arknox wants to use Nostrocket but some critical features are preventing him from doing this.


This is a problem to test if rockets can select a problem or not ffff


Problem: There is no tool to connect people and places without big tech intermediaries.

We need tools to reason about places and locations that aren't subject to control by big tech.


Problem: We don't know which way North is in the Yondar UI

Add a compass / North indicator to Yondar's UI

what happens

Currently I do not see a compass / north indicator on Yondar.

suggestion

We all need a northern star! Compass should show the North direction clearly.


Problem: <Marker> components are not a sustainable way to visualize all Places

As more places are added to the map, they are displayed with the <Marker> component. This component is not as efficient as using Source+Layer components, and so we need to migrate Places to be displayed with Source+Layer and only use <Markers> when contextually appropriate.

Rather than using <Markers> all the time, which is not sustainable, they could be used only under a certain condition. My original idea for this is that when you place your cursor, places within a fixed radius (distance) of the cursor would be rendered as a Marker, making the place appear to pop out of the map.

When places are not being displayed by a Marker, they would be displayed as part of the map in a <Source><Layer>. This makes the place a 2D point on the map that can be customized with some kind of visual icon.


Problem: There is no neutral shared digital space in which humans can communicate and act

While Yondar is a great tool for communicating about digital abstractions of real places, it is not totally neutral. The Yondar client could be opinionated about the kind of data it accepts or how it formats it. This opinion may conflict with other geospatial clients.

There ought to be a completely neutral protocol for humans to communicate about places. In order for this communication to be moderated, as communication is inherently costless and potentially infinite, that communication must be regulated by an impartial mechanism beyond a particular dev's opinion. This regulation serves to throttle the volume of communication back from infinity, make a dent in spam, improve the signal of the communication, and conserve relay resources.

Possible solution:

Create a protocol on top of nostr that enables permissionless and consistently formatted communication about places governed by a mechanism that is totally impartial.


As more places are added to the map, they are displayed with the Marker component. This component is not as efficient as using Source+Layer components, and so we need to migrate Places to be displayed with Source+Layer and only use Markers when contextually appropriate.


Rather than using Markers all the time, which is not sustainable, they could be used only under a certain condition. My original idea for this is that when you place your cursor, places within a fixed radius (distance) of the cursor would be rendered as a Marker, making the place appear to pop out of the map.

When places are not being displayed by a Marker, they would be displayed as part of the map in a Source + Layer component setup (typical Mapbox react architecture). This makes the place a 2D point on the map that can be customized with some kind of visual icon and it will be highly optimized for rendering.


Problem: There is no concept or prototype of an app with mass market potential

We need an idea for an app that enables communication as described in the above problem and it needs to have base mechanics that are useful to people and a brand that can be appealing and recognizable.


Problem: Paragraph and Page fields do not escape HTML properly ⚠

The text inputs to a problem aren't treating bracketed text properly. At best this is precluding the use of brackets in the problem description, which may be useful for talking about JSX. At worst, this may be an XSS vulnerability, where someone could inject malicious JavaScript

The text should be output into the interface through a sanitizing function. ReactJS does this by default with anything output via {} curly brackets.


Problem: place markers do not overlap properly

Due to a quirk in how react-map-gl's map component works, ordering the markers is more difficult than it seems

It would seem more correct for the place markers to be a lower z-index (farther from the viewer) as they got closer to the north or south pole, as the Earth is normally viewed from the equator.

To change the z-order of the markers, I have only found the `key` property of the `<Marker ...>` to be effective at influencing the sort, which appears to be standard alpha sort. Right now the `key` is the place id (event id). This is useful because it prevents React from re-rendering the `<Marker ...>`s many times which causes ugly content flickers.  However, the problem is that the beacons are not sorted properly by latitude and rather are sorted quite randomly by event id.

The solution may be to use a <Source> with beacon coords and a <Layer> to display a flat beacon indicator, and only have a marker pop up under a certain condition, because already there are enough markers to cause log in the render loop.

Possible solution:
- make markers only appear at a certain close zoom threshold; before that, the places are only represented by some small indicator rendered by a `<Source><Layer/></Source>`


Problem: users cannot be easily identified in UI

Geochat messages and place owners should have their NIP-05 identity, avatar, and username displayed.

- [ ] show NIP-05 in geochat
- [ ] show NIP-05 on place details


Problem: markdown checklists are not supported

GitHub style markdown checklists would be useful for identifying specific steps that should be accomplished


Problem: There is no nsec login which prevents people who have exported identities from logging in

People who backup their identity may want to login on another device with the same account. We should enable this, but provide ample warnings against using nsec login so people understand the risks.


Problem: The state of the Yondar map does not reflect ongoing and current activity related to places

Besides when a place is added, moved, edited, or deleted, the map does not change to reflect current conditions or activity relevant to the places depicted.

Things such as a person mentioning a place on nostr, reviewing a place, commenting on a place, or visiting a place could be aggregated and displayed in the UI to give the user a perception of current and ongoing "trending" activity related to places:

Place mentions mockup:

![Place mentions mockup](https://user-images.githubusercontent.com/64376233/282520477-2a3e960e-2388-401e-aba2-8141ea9c09d4.png)


Problem: Displaying current "trending" info in a place details panels will hide it too deeply

We don't want to limit "trending" information to the place details panel because that panel is only visible when the place is clicked

There should be a clever UI for conveying trend information. This may or may not be directly on the map.

Some example ideas:

- the appearance of the place changes; details available in the panel
- there is a new UI panel apart from the map to display trend information


Problem: child problems are not accessible nor visible on the problem detail view

When viewing a problem's page, its child problems should be listed somewhere so the problem tree may be easily traversed


Problem: aggregating place visits is a privacy problem that must be solved carefully

The places a user visits should not be public unless the user chooses to reveal this, but it may be possible to aggregate visit data in a privacy-preserving way.

There are powerful benefits to keeping some kind of record of when a user visits a place:

- gamification
- analytics
- trending algorithm

However, the way in which place visits are done must preserve the privacy of the user and give them control of this data while maximizing their ability to participate in the above.

This is essentially the analytics versus privacy problem.

How do we allow users to privately and optionally track the places they visit while also enabling analytics and trends?

What is the best way to enable users to publicly track their visits if they choose to do so?


Problem: people must be able to easily communicate about a place

Communication comes in many forms: likes, zaps, quotes, reposts, comments, mentions, reviews, visits

Possible solution: Implement likes, zaps, quotes, reposts, comments, mentions, reviews, visits for places


Problem: no UI design to communicate zap information about a place

Zaps contain a tremendous amount of data besides a bitcoin tally; communicating this data should be pondered exhaustively.

Inside the geospacial/visual context of a map there are nearly an infinite ways that we could display the aggregate of a place's zaps.

Examples for inspiration:

- lightning effect striking the place is proportional to the amount of zaps
- places with large amounts of zaps glow
- zaps appear as lightning icons floating around the place when you click on it to reveal the details panel

Simply showing the zap total is pretty boring and perhaps not even that useful. Showing the amount of zaps received in the last X time window, like 1 week, might be more useful for identifying trends.


User should be able to post a review of a place. The nostr protocol NIP-32 should be utilized. The review could appear as a comment but with a rating attached.

## Required reading

https://habla.news/u/arkinox@arkinox.tech/DLAfzJJpQDS4vj3wSleum

## User Story

As a Yondar map explorer, I would like a way to see how Yondar-erers rate a particular location, so that I can become more informed about a particular location.

### Acceptance Criteria

1. There is a clear method to see location ratings on a selected Yondar location

### How Might We Design

Suggested scale: add a three tier scale for rating a location/business.

~~Positive: 😀~~ Positive 👍
~~Neutral : 😐~~ Mixed Reviews 🤨
~~Negative: 😞~~ Negative 👎

### Mockup

<img width="327" alt="Screenshot 2023-11-13 at 10 29 24 AM" src="https://github.com/innovatario/yondar-mono/assets/64376233/bdfdd549-c29b-44d1-816b-24a485e8fcf6">

_Future_

Over time can expand to multiple categories/metrics. See example below.

![image](https://github.com/innovatario/yondar-mono/assets/64376233/21dc8293-f065-4ba0-acf7-0f7f52be3459)


Problem: useful review information is often posted outside the context of Yondar or even reviews

People talk about places all the time. It would be beneficial to figure out a way to grab this nostr content and associate it with a place.

![image](https://github.com/innovatario/yondar-mono/assets/99223753/1756949f-be44-4944-83b1-ab1e3ae9ba47)

Using LLMs, DVMs, or simple keyword search, we could try to associate content with a place.

In the case of Tokyo Banana, perhaps the creator of the place can define their "key identifier" which in this case would be "tokyo banana". A simple text search of nostr notes for "tokyo banana" would allow us to fairly trivially associate these notes with the place.


Problem: without location information, an external review could be applied to the wrong location

Think McDonalds: if you complain about your local store, does it show up on every McDonalds on the map in the world?

If there are many franchises, a review for one could inappropriately be applied to another location or all locations (think McDonalds)


User should be able to post a review of a place. The nostr protocol NIP-32 should be utilized. The review could appear as a comment but with a rating attached.

## Required reading

https://habla.news/u/arkinox@arkinox.tech/DLAfzJJpQDS4vj3wSleum

## User Story

As a Yondar map explorer, I would like a way to see how Yondar-erers rate a particular location, so that I can become more informed about a particular location.

### Acceptance Criteria

1. There is a clear method to see location ratings on a selected Yondar location

### How Might We Design

Suggested scale: add a three tier scale for rating a location/business.

~~Positive: 😀~~ Positive 👍

~~Neutral : 😐~~ Mixed Reviews 🤨

~~Negative: 😞~~ Negative 👎

### Mockup

<img width="327" alt="Screenshot 2023-11-13 at 10 29 24 AM" src="https://github.com/innovatario/yondar-mono/assets/64376233/bdfdd549-c29b-44d1-816b-24a485e8fcf6">

![comment-style review UI idea](https://user-images.githubusercontent.com/64376233/281255319-e5a3f375-3d87-4485-bf3a-5853dc3c9e53.png)

_Future_

Over time can expand to multiple categories/metrics. See example below.

![image](https://github.com/innovatario/yondar-mono/assets/64376233/21dc8293-f065-4ba0-acf7-0f7f52be3459)


Problem: when editing a problem, pressing the space bar immediately saves the problem and closes it

Hard to edit a problem without the space bar!


Problem: When editing a problem, the rocket selection does not default to the previously selected

The rocket selector should always default to the "current" rocket so that it isn't inadvertently changed to Nostrocket whenever you edit a problem.


Problem: sharing Yondar links do not provide useful previews of the place

Because sharing a place link is so specific, it would be helpful to provide place info in the link preview

_what happens currently_

When sharing on nostr and opening with Iris/Snort, and Damus, result is a gibberish link with little context.

![image](https://github.com/innovatario/yondar-mono/assets/64376233/95091fd4-fbbc-4de3-919e-85f2a8187706)

_what I think should happen_
There should be a preview with:
1) a static image of the location of interest
2) title text displayed on said image of location

Static screenshot of yondar below without modificaitons.

### Mockup
![Preview Map on Nostr Post](https://github.com/innovatario/yondar-mono/assets/64376233/6741fc8c-fbd5-494c-ad88-89382510f03f)

In order to provide place-specific previews, we need to have the server generate a preview image based on the naddr and then update the open graph meta tags to reference that image before the response is sent.

This is how @fiatjaf implemented njump, which I see as an analogue & potential example https://github.com/fiatjaf/njump


Problem: Nostrocket.org looks less legitimate without a proper favicon

To increase usage and trust, we must present nostrocket professionally

Svelte icon is cool but let's make it something official and branded.


Problem: user dashboard is generally not very informative

view account button leads somewhere external (good but we need better)
Just having a way to display your profile would be very importent because it enables to see all the places a user tagged, reviewed, liked or been to ? (etc.)

having a social graph helps people to feel less lost and maybe more control of places they liked commented etc.
You could also introduce the zapping easier?

For a business owner it could mean a control panel of places he has under his name
Or an artist who can manage his VR/AR art installations.


Problem: the nostrocket relay is not backed up anywhere

If something happens to the relay at nostr.688.org, there's no backup to recover from.

Solution: make it easy for anyone to republish (to any relay of their choosing) all the events that are included in the current state. That way I and anyone else can backup to a local relay etc.


Internal links to People's profile or to user => showing basic metadata


Problem: user names appear as "undefined" which hinders the usefulness of comments and problem attri

We need to enable discussions around problems but if you don't know who you are talking to the discussion may not be useful


Problem: monitoring nostrocket activity is difficult

Only the current state is shown in oxygen. It would be beneficial to see a feed of state changes. In particular, new problems by rocket, problem status changes, new users added to tree

Make a feed on the individual rocket page that shows a timeline of problem status changes, problem comments, and new problems


Problem: people are unable to fully communicate about places

Communication comes in many forms: likes, zaps, quotes, reposts, comments, mentions, reviews, visits

Possible solution: Implement likes, zaps, quotes, reposts, comments, mentions, reviews, visits for places


Problem: can't see the activity of users

We cannot see the activity of users, including our own activtiy.

We cannot see the activity of users.

Possible solution: internal links to People's profile or to user => showing basic metadata

https://nostrocket.org/problems/fcaccc67380775da3dbefb3f8218d9fdb11696b4db5efef9c59aed95b1ed5b7f


Problem: People cannot make private Places and selectively reveal them to other users.

You should be able to create private places that are encrypted and only visible to you. Then, there should be an option to share private places somehow.


Problem: users cannot share lists of places

Lists of places makes sense because most destinations will contain groups of many places that you may want to know about. Nostr list support for places can fix this.

If you go to a destination, like a theme park, you'll only want to see that park's places while you are there. Likewise, you'll want to see all the places the park has to offer: entrances, bathrooms, concessions, rides, parking, etc. A destination may contain many places and it makes sense to group places in order to make them easier to share and filter by.

In yondar.me, this feature is called a "World". A world is just a list of places with some metadata. Worlds can have a logo and banner, a title, and even unique challenges/scavenger hunts associated with them. I'd like to keep this terminology going forward.

In Go Yondar we can implement NIP-51 lists so users can create lists of places. Then, these lists can be linked to via their naddr. However, users could pay to purchase a unique custom short URL for their world, like go.yondar.me/disneyland and the app will route to that world.

The cost of the custom URLs will be proportional to their length, with short URLs costing more sats.

This is how we can begin to monetize Yondar's merits!


Problem: people don't know they can put their business on Go Yondar

Someone could set up Google Ads for searches relating to business, maps, google maps, google business, etc. And direct traffic to a business onboarding landing page (that doesn't exist yet) on Go Yondar


The Problem Tracker tree is hard to browse. We need something that scales.

Indentation only works on a small scale. 30 levels/children down this will become impossible on desktop, let alone mobile.


Problem: users cannot create a list of places

Users should be able to create a list, give it a title, and add/remove places from it. They should also be able to see and manage their lists.


Problem: world URLs are unwieldy and too long for easy sharing

In order to allow short custom world URLs, we should allow users to pay to associate a route like go.yondar.me/myworld with one of their worlds (place lists).

Payment is necessary because the route namespace is limited. Shorter names should cost more than longer names.

Similar to domains, we should consider requiring recurring payments in order to keep custom URLs so squatters cannot squat indefinitely.

Payment should be made in bitcoin (on-chain) so that merit holders can get paid directly via nostrocket through this mechanism.

The authoritative list of world URLs can be stored in a kind 30001 list published by an official Yondar key held in an nsec bunker.


Problem: no nsec bunker is configured for Yondar to sign the official world url list


The problem tracker tree needs to be displayed in a way that scales and is easy to browse

Indentation will not work past 20 or so levels, especially on mobile. It also makes it hard to see problems of the same level. A different UI for this extremely deeply nested tree is needed.


Problem: usernames often appear as "undefined" in the problem tracker

We need to enable discussions around problems but if you don't know who you are talking to the discussion may not be useful


I want to make the problem tracker easier to use, but first I need some help to figure out attributes a good design should include.

Solution: ask UX designers on nostr to document some example ideas and post links here


Problem: can't tag people in problems or comments on problems

Wanted to tag Arkinox in a problem that he told me about, but I can't easily do that.

It's not currently possible to tag people in problems or comments on problems.

Solution:
When user types @ symbol, search the identity tree for `.Name` and `.displayName` on each user's profile, add their pubkey to the tags just like any other nostr client.


It's not currently possible to tag people in problems or comments on problems.

Solution:
When user types @ symbol, search the identity tree for `.Name` and `.displayName` on each user's profile, add their pubkey to the tags just like any other nostr client.

To search the identity tree: `$consensusTipState.Rockets.get(nostrocketIgnitionEvent).Participants...`

Or log a child problem for me to export a search function


Problem: we are not publishing to user's relays

When people comment on a problem, we are not publishing the event to their relays

When people log a new problem, or comment on a problem, we are not publishing that event to their own outbox/inbox relays or their nip5 relays, we are only publishing it to the relays hardcoded in the Oxygen client.

Solution: find out how this works with NDK or if we have to do it manually by checking their relay set etc

Also re-publish the problem/comment that they are replying to so they have it on their relays.


Problem: oxygen doesnt work if we have more than one relay

it only works when connect to wss://nostr.688.org


Problem Lets talk about UI UX design and Layout fixes we can do ASAP!

Your Ideas plus designs are more than welcome! Brainstorming Ideas and then logging subproblems!!

Question: What pages are important for this product to work ?


Problem all the Links are not opening in a new Tab

I dont like when i get redirected from a page and its not opening a new tab ....

How to Fix: add on all the external links at footer  or from profiles a Visit Example


eg: blowater was added by sherry after neil was added by G , however blowater is number 4 and neil is number 31


Problem: didnt take blockheight in  to consideration when try fixting identities wrong order proble

I fix the identites order  problem, the parent problem of this one,  at https://github.com/nostrocket/oxygen/pull/64
but i didnt take block height into consideration, only create_at

I could do it when i have time but im happy of there are someone else who also wanna work on it


Problem: oxygen doesnt work when adding more relays

currently it only works when only connect to wss://nostr.688.org


The UI of the problem tracker needs to be explored with visual prototypes

Displaying the deeply nested problem tree in a way that works for the user is a complex UI problem to solve. Therefore we need many ideas and visualizations of what could work.


Idea 1:
![Note](note1ylv7e8e5lug86xa9lsjdp5r22wqzy0saje6326qv3xeu3q2epflstwjynk)
![Alt Text] (https://cdn.satellite.earth/92859bb5caa42c34c710d529e469905101d40fbcce62823286b694d29cec18ae.png)


[Figma File] (https://www.figma.com/file/XzjwS5xATDkLnViXo9oODX/Nostrocket?type=design&node-id=67%3A1180&mode=design&t=Hk3c5lGT7kd356sW-1)

Idea 1:
[Note] (https://njump.me/nevent1qqsz0k0vnu607yrarwjlcfxs6p498qpz8cwevag4dqxgnv7gs9vs5lcpp4mhxue69uhkummn9ekx7mqzyz55xnhpvhksrv5xhm8uyac779c96dfh6pgm8peg3zvvcqx4ezzmul3tenj)

![Alt Text] (https://cdn.satellite.earth/92859bb5caa42c34c710d529e469905101d40fbcce62823286b694d29cec18ae.png)


Problem: there is no component to display a user's profile/info

We need a component to serve as the user dashboard/info panel


Problem: can't see the user board for other users

Right now we can only see our own user board under the Y button menu. It would be very helpful if opening the details panel for a place would also pop-up the user board for the place's creator as a pop-over at the bottom (mobile) or bottom-right (desktop) of the screen.


[Figma File] (https://www.figma.com/file/XzjwS5xATDkLnViXo9oODX/Nostrocket?type=design&node-id=67%3A1180&mode=design&t=Hk3c5lGT7kd356sW-1)

Idea 1:
[Note] (https://njump.me/nevent1qqsz0k0vnu607yrarwjlcfxs6p498qpz8cwevag4dqxgnv7gs9vs5lcpp4mhxue69uhkummn9ekx7mqzyz55xnhpvhksrv5xhm8uyac779c96dfh6pgm8peg3zvvcqx4ezzmul3tenj)

![Alt Text] (https://cdn.satellite.earth/92859bb5caa42c34c710d529e469905101d40fbcce62823286b694d29cec18ae.png)

Idea 2:
[Note] (https://snort.social/note19duh9mzm570nr8nvvv5aap4dkm7wx8ex8g69z0q7pgtwpzjgg2eqfs2njn)


Problem: UI does not provide an easy way to see a contributor's closed/solved problems, merits, etc

It would be useful if you could click on a person in the identity tree to see a page with their merits, contributions, claimed problems, solved problems, comments, claim/solve rate, subordinate tree users, and other useful info.

Providing these insights will make nostrocket more convenient and rewarding to the end user.


Problem: it's not always clear where a new Problem should be located in the tree

When creating a new Rocket, users need to select an existing problem or log a new one. When logging a new one, it's usually not obvious where in the tree the problem should go (which problem it should be logged under). This problem is intended to be a temporary location where people new to Nostrocket can log a problem for their new Rocket and have a Maintainer relocate it to the appropriate part of the tree (which may often require logging a new head problem).


[ dsf gdfg dfgdfg dfg ]asdg dsg dfgdfgdfsg dfgd fgd fgds gdfs gsdfgdf read more using a Nostrocket client.


[ Problem: no one can see the go.yondar map unless the person is sign in ]Letting everyone take a look is increasing the popularity of yondar read more using a Nostrocket client.

Potential workflow => I'd like to show the map, but have an overlay on it that fades to black; if you scroll, it will go up over the map and show the same intro text message conversation as usual. Clicking on the map will remove the intro

Routes: / Map with intro overlay
/dashboard Map
So clicking the map brings you to /dashboard


[ Problem: status filter keeps resetting to "all" ]Problem status filter resets to "all" whenever we navigate back to the problem page. For example, I set the filter to "open", then view a problem, then go back, and the filter has changed from "open" to "all". read more using a Nostrocket client.


Problem status filter resets to "all" whenever we navigate back to the problem page. For example, I set the filter to "open", then view a problem, then go back, and the filter has changed from "open" to "all".

This is annyoing for fairly obvious reasons.

Possible solution: use `localStorage` API.

This is a good first issue for someone who wants to work on Nostrocket.


[ Problem: kind 1 notes without an expiration show up in Geochat in perpetuity ]Geochat should only show kind 1 notes younger than 7 days old so that spam and clutter is reduced and proper conversations can be the focus. Other clients do not attach an expiration to their kind 1 geotagged notes, so we can't rely on this (Yondar puts an expiration on them) read more using a Nostrocket client.

Right now, when you post a kind 1 note via Geochat in Go Yondar, the note has an expiration tag attached to it with a 7 day expiration. However, other notes posted outside of Go Yondar do not have such an expiration. We should change how Geochat interprets kind 1's such that any note older than 7 days is not shown.

Reasons for this:

- proper conversations will probably take place within a shorter duration/timeframe (hence "Geochat" and not something like "Geoforum")
- kind 1 spam will disappear after a week
- if you post something stupid it will sort of be gone in a week
- other clients won't dominate the Geochat feed simply because they don't put an expiration on their notes


[ Problem: Place data structure is too inflexible and doesn't support OSM tags nor Schema ]Places need to be more flexible in the data they can contain, and should support both Schema/Place structured data and OpenstreetMap tag data. read more using a Nostrocket client.

The current definition for a kind 37515 Place is very rigid. It can be seen in yondar-mono.git/src/libraries/defaultPlace.tsx and yondar-mono.git/src/types/Place.tsx.

In order to support more robust and dynamic content on the map, we must make the Place data specification more flexible.

Schema has been suggested as a possible solution to improving the structure of the data within a place: https://schema.org/Place
Schema is fairly rigid and made for search engines, which do not currently care about nostr.

On the other hand, OpenStreetMaps' tagging system is a very loose optionalnamespace:key=value tagging system that is use very effectively. Being that the data from OSM may frequently be copied into Yondar by individuals creating places, it makes sense to support this kind of tagging format.

OSM tags and Schema are very different tag systems. Schema also has nested objects, whereas OSM tags are a flat k=v list.

Obviously, the problem with so much looseness in the Place structure is coding the UI to interpret these variable tags. If a tag is improperly formatted, or not accounted for, critical information that would otherwise appear may be invisible.

Possible Solutions/Paths forward

- create a UI button that will show all properties for a Place in a basic k=v format; this will enable all properties to be available regardless of whether the UI is programmed to handle them.
- create a `properties.schema` key and a `properties.osm` key in the Place to store the tags separately; this will at least let the UI know which key to look at if it is programmed to handle one type or another. It enables nested data structures to exist under the `schema` key, whereas flat OSM data structures would be under the `osm` key.

The solution to this problem includes making a decision on whether/how to support both Schema and OSM.


The current definition for a kind 37515 Place is very rigid. It can be seen in yondar-mono.git/src/libraries/defaultPlace.tsx and yondar-mono.git/src/types/Place.tsx.

In order to support more robust and dynamic content on the map, we must make the Place data specification more flexible.

Schema has been suggested as a possible solution to improving the structure of the data within a place: https://schema.org/Place
Schema is fairly rigid and made for search engines, which do not currently care about nostr.

On the other hand, OpenStreetMaps' tagging system is a very loose optionalnamespace:key=value tagging system that is use very effectively. Being that the data from OSM may frequently be copied into Yondar by individuals creating places, it makes sense to support this kind of tagging format.

OSM tags and Schema are very different tag systems. Schema also has nested objects, whereas OSM tags are a flat k=v list.

Obviously, the problem with so much looseness in the Place structure is coding the UI to interpret these variable tags. If a tag is improperly formatted, or not accounted for, critical information that would otherwise appear may be invisible.

Possible Solutions/Paths forward:

- create a UI button that will show all properties for a Place in a basic k=v format; this will enable all properties to be available regardless of whether the UI is programmed to handle them.
- create a `properties.schema` key and a `properties.osm` key in the Place to store the tags separately; this will at least let the UI know which key to look at if it is programmed to handle one type or another. It enables nested data structures to exist under the `schema` key, whereas flat OSM data structures would be under the `osm` key.

The solution to this problem includes making a decision on whether/how to support both Schema and OSM.


[ Problem: need a test problem to try out creating a new rocket ]I want to test the rocket creation process and see how it all works, there's no way to do this without logging a test problem, so this is it. read more using a Nostrocket client.


I want to see what happens when I create a rocket


I want to see what happens when I create a rocket and edit it


[ Problem: can't re-use problem tracker event destructuring code ]The way we handle problem tracker events is to destructure them into the Nostrocket state, this means that we need to put previous problem events into state to be able to view them. Q. read more using a Nostrocket client.

The way we handle problem tracker events is to destructure them into the Nostrocket state, this means that we need to put previous problem events into state to be able to view them.

What we should do instead is destructure Problem Tracker Events (`kind 1971`) on the fly when needed.

For example, instead of querying the current Nostocket state to find a problem's parents, we should read this directly from the tags in the event.


[ Problem: can't re-use problem tracker event destructuring code ]The way we handle problem tracker events is to destructure them into the Nostrocket state, this means that we need to put previous problem events into state to be able to view them. read more using a Nostrocket client.


Creating a web toolbox for decentralised Nostr & Bitcoin applications


[ Child Problem Logging to test General Problem posting flow ]Logging a new Problem as a child under this one, testing the create problem flow  read more using a Nostrocket client.


Creating a web toolbox for decentralised Nostr & Bitcoin application


[ Initial Problem State ]Start to Think BIG, and think DEEP. read more using a Nostrocket client.


[ Initial Problem State ]Start with Thinking BIG, and thinking DEEP. read more using a Nostrocket client.


[ Define The Build Stack ]Setting up the framework to create transparant open finance applications.
With simple Json object configuration
 read more using a Nostrocket client.


[ problem: comments section sucks ]the comments section of problems really sucks.

comments are not correctly nested.

Comments are repeatedly rendered.

layout is shit.

Have to resubscribe every time we open a problem because comments aren't cached anywhere.

really just sucks all round, painful and useless. read more using a Nostrocket client.


I have resolved this problem with a patch: https://github.com/nostrocket/oxygen


what are you replying to


I'm just testing something


i see


[ Problem: competing annotation schemas will make Places too confusing to use ]There are many competing schemas for annotating map data and including them all in nostr has been ruled as too confusion and ambiguous. read more using a Nostrocket client.

There are multiple competing schema standards for annotating map data with useful properties. Properties may be things like "wheelchair_access=true" or "intersection=yes". These properties are used by mapping applications to provide richer and more useful guidance to users. However, with multiple competing schemas, it's difficult to exclude one without alienating its users or data sources.

Initially my solution was to allow NIP-32-like support for any given schema that the user desired to use, but this was met with resistance as it would introduce ambiguity and ultimately result in misuse/disuse of the Place kind.

The discussion can be seen here: https://github.com/nostr-protocol/nips/pull/927

Possible Solution:

It may be possible to create a limited schema for nostr Place usage that incorporates properties consistent between competing standards. Although this is somewhat akin to creating a new standard altogether, it will at least eliminate confusion for usage on nostr. Also, part of this standard could be a mapping between other schemas and the nostr schema, such that it could possibly be automated to translate properties from one schema into nostr.


[ Problem: can't claim Merits for work done ]After a patch has been merged, the contributor should be able to submit a claim for merits. After this, existing Merit Holders should be able to vote on it.
  read more using a Nostrocket client.


[ Problem: Merit Holders can't vote on Merit Requests ]Existing Merit Holders can't vote on Merit Requests. read more using a Nostrocket client.


[ Problem: can't view merit requests ]Merit holders can't view new/open merit requests read more using a Nostrocket client.


[ Initial Problem State ]Start to Think BIG, and think DEEP.


[ Initial Problem State Problem ]Start with Thinking BIG, and thinking DEEP. read more using a Nostrocket client.


[ Problem: NOSTR's complexity and obscure lingo hinder a user-friendly, sovereign network engagement ]Navigating NOSTR is challenging due to its complex lingo and lack of clear guidance on keys, profiles, and client usage. This gap creates a need for an accessible, yet sovereign, gateway to engage with NOSTR's decentralized network. read more using a Nostrocket client.

### Problem: There is no efficient way to streamline NOSTR use without losing user autonomy

### Solution:

The phrase "losing user autonomy" in the context of our problem statement refers to the challenge of making the NOSTR network more accessible and easier to use (streamlining) without compromising the individual user's control and independence (user autonomy).

In the world of decentralized networks like NOSTR, user autonomy is a key principle. It means that users have full control over their data, identity, and interactions within the network. They are not subject to the control or surveillance of a central authority (like big tech companies). This autonomy is crucial for privacy, security, and freedom of expression.

However, decentralized networks can sometimes be complex and less user-friendly, especially for those who are new to such technology. The challenge, therefore, is to simplify the user experience (make it more streamlined) without undermining these core values of autonomy and decentralization. In other words, the aim is to make NOSTR easier to use without turning it into another centralized platform where users lose control over their digital selves.

Nostrosity, as proposed, aims to address this by providing tools and features that simplify the NOSTR experience while respecting and maintaining the decentralized, user-controlled nature of the network.


[ Problem: There is no efficient way to streamline NOSTR use without losing user autonomy ]NOSTR's advanced features and decentralized nature lack an intuitive, user-friendly approach, challenging users to engage effectively while maintaining their autonomy in the network read more using a Nostrocket client.

The phrase "losing user autonomy" in the context of our problem statement refers to the challenge of making the NOSTR network more accessible and easier to use (streamlining) without compromising the individual user's control and independence (user autonomy).

In the world of decentralized networks like NOSTR, user autonomy is a key principle. It means that users have full control over their data, identity, and interactions within the network. They are not subject to the control or surveillance of a central authority (like big tech companies). This autonomy is crucial for privacy, security, and freedom of expression.

However, decentralized networks can sometimes be complex and less user-friendly, especially for those who are new to such technology. The challenge, therefore, is to simplify the user experience (make it more streamlined) without undermining these core values of autonomy and decentralization. In other words, the aim is to make NOSTR easier to use without turning it into another centralized platform where users lose control over their digital selves.

Nostrosity, as proposed, aims to address this by providing tools and features that simplify the NOSTR experience while respecting and maintaining the decentralized, user-controlled nature of the network.


Pioneering Universal Sovereignty in the Decentralized Digital Realm.


A open web stack to develop bitcoin standard web applications


[ Create Faster Iterations of applications  ]Building and Testing production ready mirco / web applications take allot of reconfiguration time especially if the build stack is too bloated, therefore a small bitcoin and lightning focused webstack framework will help in testing  more niche applications
 read more using a Nostrocket client.


[ Problem: Identify Webstack ]Define & Identify the fist Webstack to continue component development in read more using a Nostrocket client.

Sub Goals:
- Nostr Client Side
- Language Agnostic
- Static Hosted
- FOSS
- No Maintenance Fees
- Bitcoin / Lightning Standard

Current Stack State:
- Nuxt JS
- Tailwind
- Pinia
- Bitcoin Design
- NDK
- i18n

Current Custodial Implementations:
- Blockstream / ( Bitcoin.sx )
- GetAlby / ( Lightning.eu )

Config State:
NixOS ( Typescript )


[ Problem Nostrosity lacks a dedicated relay ]Nostrosity requires a personal relay to improve its connection and performance within the NOSTR network. This dedicated relay is essential for stable, efficient, and uninterrupted service for Nostrosity users. Currently, the lack of a personal relay limits the platform's effectiv read more using a Nostrocket client.

Nostrosity requires a personal relay to improve its connection and performance within the NOSTR network. This dedicated relay is essential for stable, efficient, and uninterrupted service for Nostrosity users. Currently, the lack of a personal relay limits the platform's effectiveness and user experience.

To solve the problem of needing a personal relay for Nostrosity, we'll set up the nostr-rs-relay on an Elastic Beanstalk environment supporting Docker and PostgreSQL.  The relay will be available at wss://relay.nostrosity.com, providing a reliable connection for users.


[ Problem: /place/naddr link brings logged-in users to preview page and hides dashboard button ]BUG: Clicking a /place/naddr link while logged in will yield a place preview page that has no buttons to access the main dashboard.

The expected behavior is that the link should take you directly to the map and bring the place into focus. read more using a Nostrocket client.


[ Problem: Building decentralised web apps requires allot of components  ]Building decentralised web applications requires you to have knowledge of allot of different components.
- Initial & Sustainable funds
- Operational Costs
- Development stack
- Communications
- Hosting read more using a Nostrocket client.

Building decentralised web applications requires you to have knowledge of allot of different components.
- Initial & Sustainable funds
- Operational Costs
- Development stack
- Communications
- Hosting
…
Just to name a few and most of these components aren’t event talking about your unique attributes.
One way to turn on the development jets is by standardising and boiler plating processes and flows.
As with a previous attempt at trying to tackle this problem the lessons learned will be part of this build.

Solutions List:

- Sustainable funding through open finances.
Open finances but the entire order verification at the sellers responsibility.
This includes all transactions on chain and over lightning are visible and easy shown.
These are not limited to purchase transactions ( operational costs ), development bounties, sales and transactions between lightning and cold storage.

- Operational Costs & Hosting
Still a true believer in the Zero costs model, ! No barriers for entry
Static Hosting is an easy solution and future possibility for decentralised hosting (chunkey monkey)

- Communications
The Systems comes with a simple blogging system

- Self Sovereign Stack
 During the development of the MVP certain critical components are necessary to create stable checkout procedures, these components are shared and open for people to self host but are facilitated by our funded servers.

Conclusion;
The PWA boilerplate needs to be statically hosted with a simple json config. Allowing you to focus on the application part of the build, while having a reliable payment flow.


[ Problem: Setting up a continues boilerplate launch fest ]Initial Developer Funding Incentives   read more using a Nostrocket client.


I have resolved this problem with a patch: https://github.com/nostrocket/oxygen/commit/2999c1df57c973a53cc6892c1eaa659364cfa91e


so i'd seen this nostrocket word around here and there so i read a bit more of the site

it's a distributed consensus!

is there some reason why you are borrowing the stake fraud as a membership filter instead of using a simple membership voting system for admission?

i presume it's also based on the 2/3 minimum BFT of the 1999 pBFT protocol?

i agree that mechanisms to rank members of a pBFT consensus by their failures to vote with the consensus are a good thing in general but if you are not actively monitoring your node on such a system you shouldn't be a member either, so expulsion should also be a consensus decision

just my thoughts on it - i think that it's a straight up fraud calling it "stake" when trust only needs to satisfy 2/3 correct, and non-byzantine faults are part of that failure tolerance and automatic systems of changing membership can be gamed

that last point is my biggest gripe with the staking membership competition

having a lot of money is not the same as being trustworthy, and trust is not a scoring system that can, or will ever be able to be turned into a consensus, the wreckage of failures of trust score systems in already existing history should be a warning not an encouragement to choose different ways about cluster memberships


[ Problem: Creators don't get their work distributed far and wide enough. ]Creators don't get their work distributed far and wide enough because it's siloed in different platforms. read more using a Nostrocket client.


Create a more peer-to-peer version of patronage platforms


[ Problem: tags are repeated when editing a post ]tags are repeated when editing a post read more using a Nostrocket client.


I've resolved this problem with a patch: https://github.com/nostrocket/oxygen/commit/751f5c2212d75818c1588c8414bd3adec154b886


[ Newcomers often have unanswered questions and give up ] read more using a client that supports Nostrocket problem tracking.


[ Newcomers often have unanswered questions and give up ]Newcomers often have unanswered questions and give up when they can't find answers. read more using a client that supports Nostrocket problem tracking.


When people come to the nostrocket site for the first time and something is confusing or doesn't work, we lose them.

Solution: begin capturing these questions so that they can be used for an FAQ.

The simplest way to do this would be to put a "help" button somewhere in the menu and use a comment form where the user can ask a question. This can then be published as a kind 1 note.

The note should tag me (gsovereignty) for now, since I'm probably the only one who's going to answer at this phase of development. Probably good to also add #nostrocket to make them easy to find.


[ Can't see what actions I need to take in relation to problems ] read more using a client that supports Nostrocket problem tracking.


[ Can't see what actions I need to take in relation to problems ]I can't see what actions I need to take in relation to problems without going into each problem individually and opening the "actions" tab. read more using a client that supports Nostrocket problem tracking.


There are a variety of actions that users can take in response to problems, but there's no unified queue that users can see when an action is required. They have to open each problem individually and go to the actions tab to see if they have action required.

For example, if I log a problem and someone patches it, I need to close the problem if it's solved. But I currently have to go through every problem in the entire problem tracker to see which problems require this action to be taken.


I've resolved this problem with a patch: https://github.com/innovatario/yondar-mono/kfgjhdsjkgfhsdg


I have voted to blackball this request for Merits.


I have voted to ratify this request for Merits.


[ No indication that user is not in Web of Trust ] read more using a client that supports Nostrocket problem tracking.


[ No indication that user is not in Web of Trust ]When a user is not in the WoT the "new problem" and "work on this problem now" buttons appear to be broken. read more using a client that supports Nostrocket problem tracking.


Solution: indicate to the user that they need to be in the Web of Trust to claim problems.

Allow anyone to log a new problem regardless of WoT status, and if we have problems with spam just disregard events from people who are not in the WoT.


[ Everyone is using nostr wrong ] read more using a client that supports Nostrocket problem tracking.


[ We are not parsing bloom filter events ] read more using a client that supports Nostrocket problem tracking.


[ Keywords need to be regenerated every load ] read more using a client that supports Nostrocket problem tracking.


[ We are not including all available metrics in event ranking ] read more using a client that supports Nostrocket problem tracking.


We now have two metrics: RAKE ranking, and WoT interaction ranking (replies etc), but we are only consuming the RAKE rankings right now. Should find a way to optimize by including the interaction ranking too.


[ Changing pubkey does not refresh all data that should be refreshed ] read more using a client that supports Nostrocket problem tracking.


[ Profile pics don't always refresh ] read more using a client that supports Nostrocket problem tracking.


[ Profile pics don't always refresh ]Profile pics don't always refresh, sometimes they are from other pubkeys. read more using a client that supports Nostrocket problem tracking.


[ Datestamp is hard for humans to reason about ] read more using a client that supports Nostrocket problem tracking.


[ Datestamp is hard for humans to reason about ]Datestamp is hard for humans to reason about. Use relative time instead. read more using a client that supports Nostrocket problem tracking.


[ Layout on mobile gets blocked by android nav bar ] read more using a client that supports Nostrocket problem tracking.


[ Can't view youtube videos when url is included in a note ] read more using a client that supports Nostrocket problem tracking.


[ Not clear when user is logged in ] read more using a client that supports Nostrocket problem tracking.


Change login icon to their profile pic when logged in. Make login icon orange or something to draw attention to it.


[ Width of YT video iframe overflows message bubble ] read more using a client that supports Nostrocket problem tracking.


[ Profile name and avatar don't consistently update when navigating through threads ]Profile pics don't always refresh, sometimes they are from other pubkeys. read more using a client that supports Nostrocket problem tracking.


[ Profile name and avatar don't consistently update when navigating through threads ]Profile names and pics don't always refresh, sometimes they are from other pubkeys. Something to do with svelte's reactivity. read more using a client that supports Nostrocket problem tracking.


I've resolved this problem with a patch: https://github.com/nostrocket/humble.horse/commit/2731f74fd7d9b90a7d2813d62c0ba071bf83e12c


I've resolved this problem with a patch: https://github.com/nostrocket/humble.horse/commit/49b19445f2a036e6de670536c0062a4ce8946b68


[ Can't interact without nip07 browser extension ] read more using a client that supports Nostrocket problem tracking.


[ Can't interact without nip07 browser extension ]Can't interact without nip07 browser extension, users can't create a new account or view read only read more using a client that supports Nostrocket problem tracking.


[ Can't view a feed without browser extension ] read more using a client that supports Nostrocket problem tracking.


[ Can't view a feed without browser extension ]Can't view the feed for any given npub without a nip07 browser extension providing the npub. read more using a client that supports Nostrocket problem tracking.


Solution: search for npubs from purple pages (or whatever) based on kind 0 event data and let user "log in" (for lack of a better term) with it.

They won't be able to sign events obviously but still a much better experience for casual and first time usage.


[ Everyone is using nostr wrong ]Everyone is using nostr wrong and it's stopping us from winning bigly read more using a client that supports Nostrocket problem tracking.


[ Don't have any printing arranged for the shirts ] read more using a client that supports Nostrocket problem tracking.


[ The shirt printers have not been paid ] read more using a client that supports Nostrocket problem tracking.