Update ANS-108.md

[twilson63]

Include the option for ArNS Subdomain

[twilson63]

This is working in the wild

https://alex-renderers.g8way.io/?tx=c2fsgEEE5UU7uUqVcP-_pqBolJonhg20SGku36-gQMQ

[atticusofsparta]

so I see a few ways of doing this.

1. have the renderer implement gql based app version redirecting. Onload it queries for newer versions of itself - if it finds one it redirects the user to it (or updates its own data, w/e). This is a more fool-proof way of making the renderer updatable, and allows for more configuration of the selection of the renderer, by both the dapp developer and the user (if the dev supplies the correct ui).

2. Utilize ANT contract ID's. Instead of putting the ARNS name as the the renderer, put the contract ID of the renderers ANT contract. This would still allow for versioning of the renderer without the worry of a domain expiring for a renderer. The owner of the ant could still change the target ID to something that is not a renderer however, so for that reason I still think option 1 is superior, since the same app would most likely be upgraded to a renderer-app. And since its an ANT tied to an Arns name, the gateway could still implement name-routing for the renderer - even if the renderer adds or changes its ARNS name.

3. Use the arns name as the use-renderer tx - IMMHO not a good way to do it in the idea of permanent long-lasting utility, due to names being able to transfer hands via lease expiry. If the point of a renderer is to reliably render that on-chain data, then it should be durable over time.

Lastly - ARNS is still a young product and is still in flux. It may be prudent to wait for it to solidify before standardizing anything around it, and it would be a good idea to consult ar.io's plans on it before making it part of a standard.

[twilson63]

This PR represents what is happening now in the field. now.arweave.dev can support either subdomain or TX_ID, but clarity should be decided upon, ArNS is in test mode so things can change over time and dependency on this may not be a great solution, one consideration is to look at ANS (Arweave Name Services) (I hope they change the name) but since those are permanent owners it could be an alternative that is contract based. IMO using graphql would be too slow.

Another option is to create a separate contract specifically for ANS-108 that connects names to owners, and owners can be either wallets or contracts, that have the ability to be read via a cache, like DRE.

Happy to do the work to create a 108 registry contract, or change the code to use Arweave Name Services it that is what the community decides, if those are not accepted then I recommend we do not consider a dynamic option and just use TX_ID's only for the Render-With value.

(Thoughts)

@mogulx_operates
@VinceJuliano
@NickJ202

You guys are currently using this proposal, please weigh in with your thoughts.

@DanMacDonald
@rosmcmahon
@samcamwilliams
@cromatikap
@t8

Any additional thoughts or ideas?

It would be great to get your opinion as well, I don't think there is a rush on this, but it would help to have some clarity as teams start to implement this proposal.

It is actually quite cool to see it working on now.arweave.dev

Maybe it is worth just letting different implementations experiment for a while until something settles as a common use. I agree with @atticusofsparta that using ArNS is a risk and implementations should consider other name system alternatives that are more permanent.

[jshaw-decides]

The common theme I'm getting from @atticusofsparta is that there's many ways to use Render-With, and I agree with this.

The ARNS approach is one method for rendering using a TX_ID. Instead of passing a TX_ID, you pass a name that points to a TX_ID. We tested it out on now.arweave.dev as an experiment but it is a "way to implement Render-With" without changing the standard.

I think this would be a cool way of getting it to work as well (from @atticusofsparta):

Though this kind of changes the standard a bit.

It's funny, I was chatting with @twilson63 yesterday about ways to do rendering better. I still don't think we have come to the final standard, and I doubt we will get there for a while.

I don't see ARNS as being a "PART" of the standard, I just see it as a different way to implement the TX_ID. Anyone could just continue to use TX_ID and could ignore ARNS all together or any other name service and it would always work.

@atticusofsparta would love to checkout anything you come up with for better approaches. I'd love to try out other name services as well, and more ways of solving the same thing.

There's all sorts of ways to solve this in a more resilient way.

@twilson63 sums it up pretty well here:

@twilson63: "Maybe it is worth just letting different implementations experiment for a while until something settles as a common use. I agree with @atticusofsparta that using ArNS is a risk and implementations should consider other name system alternatives that are more permanent."

Here's what I think we should do:

1. Keep experimenting with the standard
2. Keep documenting other ways to do it (pictures / examples in the wild preferred)

I personally would approve these changes as a record of how it's currently being used. This ANS-108 branch isn't even into master so it's not like it can't change before the merge to master. 😀

[NickJ202]

I agree @mogulx-operates and @twilson63, the best approach might be to continue trying different things out. That being said, I think it is worth noting it may be difficult to keep track of Tx IDs if they continue to change frequently. For example, if a renderer needs strictly styling changes, then we will want to deploy a new renderer that accepts the same data. That would mean an updated Renderer Tx Id that would need to be supported from an application. In this case an ArNS seems to be very useful.

[VinceJuliano]

It may be a challenge to alter a lot of those integrations we may want to consider something that works into the future, could the Render-With have a value of both an ArNS/ANS name alongside a rollback transaction ID with the original renderer for permanence? I realize this would alter the standard just a suggestion.

[atticusofsparta]

@NickJ202 This is why I feel the built in app versioning would be the best way to go - its dynamic. If you go to any version of the app, it queries gql for the latest version of itself, and routes the user to that version.

Redirect logic can include adding the params in the url for rendering.

[twilson63]

@NickJ202 This is why I feel the built in app versioning would be the best way to go - its dynamic. If you go to any version of the app, it queries gql for the latest version of itself, and routes the user to that version.

Redirect logic can include adding the params in the url for rendering.

I think it would help out a lot to see an implementation of the reverse release checks working in the wild, to demonstrate just how easy it is for developers to build renderers with built-in version redirecting. - Having a working implementation can really help solidify standards. Is anyone, up to the task?

[atticusofsparta]

@twilson63 Sure, ill build a POC, just need to do some research