The test plan is unrelated to the diff which is only documentation. Please keep the summary and test plan in sync with the changes under review.

Since it's only a single line change in documentation I'm ok with skipping the linter, however if you want to add support to cashtab you will need to linter to work.

4c6f67696e20746f2047617564696f20417070 // push "Login to Gaudio App" (17 bytes)

If the types of actions are expected to be limited and defined, it makes sense to assign a code to them. For example you could just say LOGIN for "Login to Gaudio App", or even "L"

The idea is to make OP_RETURN spec as compact as possible since the space is limited and you may wish to add more functionality / actions. There's no need to store "to Gaudio App" in the OP_RETURN since the prefix already takes care of this.

What is the intended use / experience for this? It is simple enough to add and track these kinds of txs, but keep in mind that token indexing would be more complicated than just adding the msgs.

Why the OP_FALSE? is this a version byte?

In D18656#425497, @bytesofman wrote:

4c6f67696e20746f2047617564696f20417070 // push "Login to Gaudio App" (17 bytes)

If the types of actions are expected to be limited and defined, it makes sense to assign a code to them. For example you could just say LOGIN for "Login to Gaudio App", or even "L"

The idea is to make OP_RETURN spec as compact as possible since the space is limited and you may wish to add more functionality / actions. There's no need to store "to Gaudio App" in the OP_RETURN since the prefix already takes care of this.

What is the intended use / experience for this? It is simple enough to add and track these kinds of txs, but keep in mind that token indexing would be more complicated than just adding the msgs.

Why the OP_FALSE? is this a version byte?

Actually, the types of actions will eventually be quite diverse. It’s not only about identifying that a user is logging in to one of my apps, but in the future I also plan to use this for a chat application I’m building, so the functionality will be broader. I also want every transaction initiated by my apps to carry my brand logo as a kind of signature.

You’re absolutely right that the prefix itself is already sufficient, but I still wouldn’t know which specific app the user is logging into. Since I plan to launch many different utility apps, and I also need this information for analytics, I’ll need to include some additional unique identifier in the message.

As for the OP_FALSE, I honestly don’t know its exact purpose — I just followed the pattern from PayButton. If it’s not actually required for my use case, then I’m totally fine with leaving it out.

Similarly it's unclear why you need the nonce for. Transactions are unique already.

In D18656#425502, @Fabien wrote:

Similarly it's unclear why you need the nonce for. Transactions are unique already.

That's probably a bad idea, you'd better go with what you really need instead. For reference the paybutton specification explains that the first OP_0 is a version byte, and that payload and nonce are optional fields (empty when set to OP_0).

In D18656#425502, @Fabien wrote:

Similarly it's unclear why you need the nonce for. Transactions are unique already.

You’re right — the nonce is optional. In my case as well, it isn’t needed for regular messages such as chat. However, when the user action is a login, the nonce becomes necessary.

The reason is that during login I need a way to map and validate the activity while listening on the websocket. The nonce allows me to compare the value stored locally on the client with the one received from the websocket. If they match, I can confidently link that transaction to the correct user and proceed to deliver the associated data.

It works very similarly to how PayButton functions as a kind of single sign-on. This way, users don’t need to manually input their eCash address when logging into my apps.

In D18656#425529, @nftoa wrote:

I finally started to understand how I should properly contribute changes to a few lines of code in different parts of the Cashtab folder, specifically regarding the context of the protocol ID claim. This week, I’ll work on improving the way I submit diffs:

1. I fork and run Cashtab locally for testing.
2. I add a few lines of code in different places within the Cashtab folder so that my logo can be rendered.
3. I run lint and test Cashtab locally.
4. If everything works, I commit and push the changes to a new branch.
5. I resubmit the diff to Phabricator.

It's fine to start with just the documentation of the protocol, then proceed to the Cashtab integration incrementally. We favor small and self contained diffs.
Please note also that any new feature added to Cashtab should come with a test.

This diff is not problematic, but it deserves to be cleaned up in the description (which you did) and updated to reflect the description (which you did not). Once this is done I have no problem merging it. If it happens that there is no implementation done in the future for this protocol we will simply revert the commit and remove the unused standard from our docs.