jkmartindale / ethical_targeting-backend Goto Github PK

Currently Ads contain HTTP URLs pointing to an image. It's probably ideal to host these images on-chain or something.

#1 is a stopgap solution to #2, and it's likely we won't be able to make our own ad management UI before the sprint deadline.

Even then, it would be nice to rename the "Candid UI" title to "Ethical Targeting" where possible to at least pretend this is a real UI.

It would also be helpful to hardcode the canister the UI connects to, so that it doesn't have to be specified in the id GET parameter.

Having a thing that stores ads is cool and all but they gotta get in there somehow, and preferably not by typing extremely long Candid strings into a terminal window somewhere.

The API web server could emit headers such as E-Tag and Cache-Control to facilitate browser cache of the ad ledger JSON.

Ads are currently assigned IDs as sequential Nat types. This might be safe...but I'm not sure. Internet Computer documentation says that race conditions don't happen, but then also says that "non-synchronized state changes" can happen.

We need to figure out which is true and make sure ID generation is safe. Assigning IDs "out of order" could be a problem, and if that is possible we need something to detect and correct for it.

Currently accessing the ad ledger over the Web spits out JSON of every ad in the ledger. It should only spit out JSON for currently active campaigns, which are ads that have a start time before now (if specified) and an end time after now (if specified).

Currently none of the AdsLedger actor's state is declared as stable, so every canister update wipes the ledger clean. Ideally this would not be the case.

Right now Profiles and Targets have Country attributes, but it might be useful to target location on a province level.

Judging from the difficulty we're having trying to bundle external libraries into the browser extension, relying on the browser extension accessing canister methods via Candid is probably a bad idea. There's nothing wrong with HTTP.

A few days ago I was planning on implementing a Candid <> HTTP gateway, but it looks like there's some undocumented functions that allow canisters to accept HTTP requests and send HTTP responses. More to investigate.