search

signum-network / SIPs

Signum Improvement Proposals
The Unlicense
13 stars 10 forks source link

Alias Expiration #73

Closed frankTheTank72 closed 1 year ago

frankTheTank72 commented 1 year ago

I'm not in favor of this proposal. Yes, Alias expiration is a good thing, and for businesses it is essential to have a robust/reliable renewal option. This proposal mixes up protocol and logic layers and even wants to tie up a token into this, which is problematic because of:

  • planned multichain

  • favoritism issues

My suggestion is to introduce either a new Subscription Subtype Renewal Subscription or allow Subscription to have an additional alias Id parameter, thus linking the subscription to an alias renewal. It could be even interesting to allow flexible renewal periods, e.g. 1 - 24 months, and a renewal fee according to this.

In my opinion, this solution is a pure protocol based approach, which is even easy to handle by the users.

I belief that a combination of existing protocol features can just be combined to handle the renewal - the only new thing needed, is to handle the renewal_time on the alias.

I also belief that a simple 1 year subscription is enough to handle the whole workflow - no need to have customized periods - as this is also not typical for domain registrations. In addition, we provide a simple APi call with fixed values so a subscription creation is seamless for the user.

ohager commented 1 year ago

I'm not in favor of this proposal. Yes, Alias expiration is a good thing, and for businesses it is essential to have a robust/reliable renewal option. This proposal mixes up protocol and logic layers and even wants to tie up a token into this, which is problematic because of:

  • planned multichain
  • favoritism issues

My suggestion is to introduce either a new Subscription Subtype Renewal Subscription or allow Subscription to have an additional alias Id parameter, thus linking the subscription to an alias renewal. It could be even interesting to allow flexible renewal periods, e.g. 1 - 24 months, and a renewal fee according to this. In my opinion, this solution is a pure protocol based approach, which is even easy to handle by the users.

I belief that a combination of existing protocol features can just be combined to handle the renewal - the only new thing needed, is to handle the renewal_time on the alias.

I also belief that a simple 1 year subscription is enough to handle the whole workflow - no need to have customized periods - as this is also not typical for domain registrations. In addition, we provide a simple APi call with fixed values so a subscription creation is seamless for the user.

The customizable prolongation period was just a suggestion. I have no problem to fix it to a single option only. This would make it even easier to implement.