Implementatation details of Million Lumen Homepage

[rahimklaber]

I was thinking how I could do the Million Lumen Homepage bounty but I have some questions:

• Is the intention for the project to only be a front-end application with stellar as the back-end?
• Should users be able to select which pixels they want to buy? Or can the the website decide where to place the image.

[hanseartic]

The spec is not clear on those two points. If I were to hunt it, I would probably let the user choose a pixel and the color, then sign whatever transaction is leading to the reservation/purchase of the pixel.

If you store the information in data-fields you'd need 1000 accounts on your side, as an account can have 1000 data entries - adding 0.5 XLM to the account's minimum balance each.

[Smephite]

The data could probably be stored cheaper -> 1k data entries -> 128 bytes -> 128,000 bytes per account for the reserve cost of 501 XLM.
Let's say we want to store an array of 1 million tuples (account id, x, y, 8-bit color):
One tuple requires: 256 bit pubkey, 1 bit -> x, y selector, 10 bit location, 8-bit color = 275 bit per entry * 10^6 = 34,375,000 bytes.
Thus all data stored would require 269 accounts (134,769 XLM).
Going this path a FE only would not be possible, as there would need to be a central authority to manage the data entries.
This could probably be achieved using TSS for the initial buy but subsequent transfers would require a deeper thought.
PS: Let me know if I did my math wrong :p

[Smephite]

And I did my maths wrong:
the location of course needs log_2(999,999) bits to store => 20 bits.
=> total 284 MBits => 279,297 entries => 280 accounts.

[Smephite]

I don't think a front end only solution would be possible as there would be some kind db / stellar account needed to store information. This would require server secrets. Maybe possible with TSS?

[Smephite]

It is possible to create assets with "ghost" issuers thus the cost of each asset comes down to only 0.5 XLM.
e.g. GALXUEHTAFNYYEOAUY3N5V2MNN36LIO4U7MMKYBNQYCQS56DZID2ZO6Q
The color could then be determined by account data -> another 0.5 XLM

[hanseartic]

color could also be encoded in last 6 digits of account-id (as hex)

[Smephite]

This would require a specially created user account to hold each pixel adding another 1 XLM to the equation whereas a simple data entry would cost 0.5 XLM. imo the upfront cost for an existing account can be neglected as that's on the users side of things.
The only problem with this is that each account must only hold 1k pixels/assets at max.

[Smephite]

This limitation could be prevented by storing multiple pixels in one data entry, but this would result in different prices for each token (dependent on amount owning) voiding the idea of 1 XLM <-> 1 token

[rahimklaber]

I think you could do a front end only project by making users send payment to a certain address and using the memo field or by using manage data ops to denote the position of the image and image. The front end could then query the payments to the account. However, this would probably take a long time and There might be issues if two users try to buy the same pixel at the same time.

[kalepail]

I love all the innovative thinking going on with this bounty. My mind is really spinning with this one! 🤔

Ultimately I think 1 XLM per pixel is too much. A 256*256 square would cost ~$20,000! Maybe it should be base fee based. So each operation is a pixel.

Personally I'm also not a huge fan of utilizing external storage like IPFS but that's a personal quirk of mine with these decentralized databases. I think it'd be cool to have an interface where you can drag and drop an image around on the canvas and a transaction was automatically generated for you based on the pixels and placement of the image itself. Submit the transaction as a "save" action.

My thought is that the transaction would be for creating as many new accounts as needed and filling each with a bunch of manage data attrs for the pixel values of the image. The accounts are sponsored by some "master" billionstroop homepage account which has to finally sign off on the sponsorships. You could use Turrets for that or just your own server for now.

A method like this seems more affordable, intuitive and secure as you control all the operations for the source account and can more easily query for the status of the entire final image. Might even be able to implement some sort of big query batch job to make grabbing all the ops more efficient.

So many interesting potential ways to do this.

[kalepail]

I also don't know how I feel about using images vs individual pixels as the interaction mechanic. It wouldn't take 5 minutes for nsfw/offensive stuff to start showing up with no easy/affordable way to sensor. #yayhumans