Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notificaiton when timed auction ended #149

Open
dmtrjsg opened this issue Jun 19, 2023 · 2 comments
Open

Notificaiton when timed auction ended #149

dmtrjsg opened this issue Jun 19, 2023 · 2 comments
Assignees

Comments

@dmtrjsg
Copy link

dmtrjsg commented Jun 19, 2023

@dmtrjsg commented on Fri Feb 24 2023

Objective

Inform users about timed auction ended so it can be settled.

Runtime constraints
|
It's not possible to do it on the runtime side, it will require at each block to:

  • loop through all the nfts on chain
  • filter whether they are in english auction state
  • check whether the current block is the ending block for those in the english status state

If you would like to know the ending block for an english auction, it can be fetched from the english auction info, as it contains start block + duration


@dmtrjsg commented on Mon Jun 12 2023

@ignazio-bovo could you remind us if that is still out of question for implementation? Since we are attempting the notifications implementation we'd love to have this.. with the new Orion architecture maybe that could be included to our scope?

cc @bedeho @Lezek123


@bedeho commented on Mon Jun 12 2023

It's not possible to do it on the runtime side, it will require at each block to:

Yes, it is correct that its not possible to emit a runtime event, but that does not mean that Orion cannot detect such a milestone, because it already knows all the scheduling information. This could be done in many ways, but one simple way is for Orion to have a (private, i.e. not queryable by front-ends) entiy for Auction ending notifications. The blockchain processor is responsible for adding new notifications when an auction is created, and also cleaning up if an auction is prematurely halted or stopped (I don't even remember if this is possible), or the video/channel is deleted or osmething. On the flip-side, you have the mailing service which queries this table at relatively low intervals, say every x minutes or whatever, and removes events that have expired but where not removed before that time. It then consturcts the relevnt email and in-app notifications (these are distinct) representations. This second process should obviously be asynchronous to the first, and also not block the processor in any way in terms of database access. I am sort of hand waving a bit here, because I don't know how the general email notification archtecture is supposed to work. There are solid best practices on how to do that, so perhaps that is the best place to start even before pinning down how to power event-free notifications.


@bedeho commented on Mon Jun 12 2023

PS: Running some sort of Orion block level processor def. is not a good idea from past exprience with Hydra.


@dmtrjsg commented on Mon Jun 19 2023

Assigning to @ignazio-bovo to investiage as part of the notifications.. Moving this to Orion repo.

@ignazio-bovo
Copy link
Contributor

ignazio-bovo commented Jun 19, 2023

@bedeho

PS: Running some sort of Orion block level processor def. is not a good idea from past exprience with Hydra

can you please specify what was the main approach in that case

@bedeho
Copy link
Member

bedeho commented Jun 23, 2023

can you please specify what was the main approach in that case

This was my initial remark above, what do you think of it? ping me if you don't hear back.

This could be done in many ways, but one simple way is for Orion to have a (private, i.e. not queryable by front-ends) entiy for Auction ending notifications. The blockchain processor is responsible for adding new notifications when an auction is created, and also cleaning up if an auction is prematurely halted or stopped (I don't even remember if this is possible), or the video/channel is deleted or osmething. On the flip-side, you have the mailing service which queries this table at relatively low intervals, say every x minutes or whatever, and removes events that have expired but where not removed before that time. It then consturcts the relevnt email and in-app notifications (these are distinct) representations. This second process should obviously be asynchronous to the first, and also not block the processor in any way in terms of database access. I am sort of hand waving a bit here, because I don't know how the general email notification archtecture is supposed to work. There are solid best practices on how to do that, so perhaps that is the best place to start even before pinning down how to power event-free notifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants