Meta Protocols Plan should ord support mutiple differnt use cases for ord?

[elocremarc]

Edit: changing this to title metaprotocols so we can have a wider discussion. Edit: Original title Plan out code Preview as we add a ton of languages.

https://github.com/ordinals/ord/pull/2471#pullrequestreview-1651746855

Bit of a pain that we have to import all languages explicitly but I think it makes sense for now to keep the bundle small.

@raphjaph I kinda want to add backend and webdev media types like Rust, Typescript, JSX, TSX, GO, Python maybe others (Docker). I have a meta protocol called dapp where you store executable code in inscriptions see. You get the inscription then run them all locally lets people expand out of ord limitations. Like someone could inscribe the runes protocol once its stable. However if we start adding all these files do you think it would be worth doing autohighlight? Even if we add like 12 new languages the bundle might be smaller still but that code-preview.js is gonna get ungodly

[p0stcapone]

While I'm certain that we'd all have a pretty wonderful time coming up with rationalizations for why somebody should pay up 6.9 BTC to hold the ordinal associated with a dependency package used to animate the dickbutt, it probably makesa more sense (especially forward looking) to make a dedicated envelop for package management.

Pros:

A) "BPM" (Bitcoin Package Manager) is a good name and you can inscribe yourself to an ustable sat and be washed away into the nether if you don't think so

B) There's no real reason to care about client adoption of a new envelop...enveloping metaprotocols that want to make use of another envelope can just add indexing support of it (ord could add bpm indexing)

C) Future metaprotocols who want to use BPM but don't want to index all of ORD can develop clients that optionally participate in their relevant/useful indexes

Cons:

People will probably just publish them in inscription envelopes anyway cause the option to sell is more favorable than the absence of the option to sell.

[elocremarc]

Cons:

People will probably just publish them in inscription envelopes anyway cause the option to sell is more favorable than the absence of the option to sell.

Yeah I kinda agree here do we want people doing this? Do we want ord to be capturing all meta protocols?

@casey that was my one concern I never commented on with the meta-protocol PR#2449 they are still in the ord envelope when that might create bad practice of making everything follow ord theory like BRC-20 for instance. We still might have time to rethink that since we haven't cut a release on that PR yet.

For instance if we inscribe libraries to be used in recursion they might not even need to be bound to a sat. Benefits could be updating a recursive library with parent child if they are bound. However we don't really need them to be full inscriptions. However still having access to them in recursion would be beneficial. Pros and Cons in both camps.

Cons If we put everything into the ord envelope and have people use the meta protocol flag then we are sort of forcing ord to support that. We could do it different where a where maybe we could use the ord client as infra for indexing other metaprotocols with their own envople flag instead of making it a metadata feild. Meta protocols that won't care about ord theory like Zk roll ups for instance or BRC-20.

@psifour might have some comments here. I could change the name of this discussion around meta-protocols if it devolves into that.

[elocremarc]

I sort of said in my initial dapp inscription you don't really need ord theory see dappscription here

Envelope Format:
  This inscription is currently using the ord envelope. 
  Dappscriptions can be inscribed in their own envelop. 
  Or it can use the metaprotocol DAPP if that gets merged in ord PR #2449
  Example: 
    OP_FALSE
    OP_IF
      OP_PUSH "dapp"
      OP_PUSH 1
      OP_PUSH "text/javascript;
      OP_PUSH 0
      OP_PUSH Console.log("Hello, world!");
    OP_ENDIF
    Note: OP_PUSH 1, OP_PUSH "MIMETYPE" can be optional use shebang example #!/usr/bin/env bun

  Provenance:
  Can use PGP signatures, or other methods such as common origin of inscribing address.
  Can also use ordinal theory with parent child using the ord envelope with the dapp metaprotocol flag.

[sanjfomojis]

Not sure if this is the best place for this, but just wondering if meta protocols are displayed on any explorers yet?

We've been playing around with a POAP equivalent with GeneratOrd which is a recursion platform we've been building.

The POAP equivalent wasn't really going to be a feature and so at the moment it's just regular inscriptions using recursion. But people seemed to like our first little experiment so thinking of maybe adding it as a meta protocol to differentiate it from regular inscriptions.

Eg. https://www.ord.io/35282570

The idea is for it to be more of a memento/souvenir (for example, the one that was claimed at the Inscribed Pepe event in Inscribing Amsterdam) and not be explicitly tradable, which is why differentiating it might be a good thing.

Wondering if anyone has any thoughts or input?

Also been tossing up what to call it. At the moment, deciding between Artifact of Attendance or Relics to go with the theme @casey generally runs with.

One Relic definition is memento/souvenir, which seems fitting.

[elocremarc]

Not sure if this is the best place for this, but just wondering if meta protocols are displayed on any explorers yet?

No its merged but not in a release yet. That is sort of why I am having this discussion. Should ord support all meta protocols and if we do how should it support it to be as generic of indexing protocol as possible.

The idea is for it to be more of a memento/souvenir (for example, the one that was claimed at the Inscribed Pepe event in Inscribing Amsterdam) and not be explicitly tradable, which is why differentiating it might be a good thing.

This is why I think it could be useful in ord to make a unspendable UTXO that an inscription is sent to but cannot be spent. This would essentially make a soul bound token SBT like on ETH. This imo is useful for making inscriptions that a community can do to token gate initiatives but don't always want to make things be speculative.

it probably makesa more sense (especially forward looking) to make a dedicated envelop for package management.

@casey hot take here but should we put runes into ord as well? Seems like that is already happening anyway. However I feel like that never had any discussion. Which is what this issue is about. If we add runes then shouldn't we also add support for DAPP inscriptions like executable code like PR#2538 and issue https://github.com/ordinals/ord/issues/1481 or the original post above?

[casey]

I think it's probably undesirable to add support for different metaprotocols into ord. There are a whole lot of them, and they would take substantial review by the maintainers to figure out if they're well thought out, complementary to ord, etc. Runes is by one of the maintainers, i.e., me, so it's easier to add.

[Psifour]

@casey hot take here but should we put runes into ord as well? Seems like that is already happening anyway. However I feel like that never had any discussion.

To clarify an important aspect. Runes is not a metaprotocol built on ord as it uses a different storage mechanism (OP_RETURN vs Taproot Witness Data, see the pushback against adding OP_RETURN inscriptions for context), is tracked completely differently (UTXO-based instead of relying on Ordinal Theory), and seeks to accomplish a distinctly different objective. The only point of connection between them is that both Runes and Ordinals share a creator.