@6directions Maybe this would help you with Ergonames?
@6directions Maybe this would help you with Ergonames?
CThat does seem like a good place to use a tree
Linfinitely scalable with a single box
Lobviously "infinitely"
CInstead of limiting size of the name to 32 bytes, you could also just take a name of any size and hash it to get a unique 32 byte collection
MWow! Where can I find more details?
Ltrue, guess a hash collision wouldnt be the end of the world either
CNot sure actually, I don't know where the documentation for context vars is. I guess a good example of them being used would be GuapSwap if you want to look there
CGood point, I guess some limitation would be needed in the name size to help prevent that to some extent. Probably not a huge deal, but might be a good idea if you truly want the protocol to last forever.
LWell, it is handles we are talking about, if there is a collision you can just tell the user, tough luck, pick something else 
NSo far the blake2b256 hash function (if you use this widely used hash function on ERGO to also hasing of NFT Images - currently the EIP-0004 use sha256 instead) is collision resistance (meaning that there is not such a
x, y (where xy denote arbitrary long bit string) that x != y and blake2b256(x) == blake2b256(y) - meaning nobody found even a single collision on this hash function).
NI've checked older sha256 and it seems that it still remained also collision resistant. But yes you need to handle such case same way as you should handle private key not being equal to zero even when there's only 1 in 2^256 change (much more than the amount of atoms in the visible universe) of generating such a key.
N---
NGenerally storing of whole images on-chain doesn't make a sense. However you can always store some simple pixel-art. Somebody could even make a standard for such a thing.
NThat a great idea to store vector NFT images, to be honest it didn't came to my mind to use vector images in this scenario - it could be useful to store big and complex images made of basic shapes (thus being represented by their vector form).
NHowever using default XML format used in SVG and converting it to even less space effective base64 is really waste of blockchain space - such an incredible waste of space!!!
NWhy do even bother with doing base64 when you can represent the XML in ascii bytes in the first place?
NAnother thing - you can build your own compression format or use something available (if any) to heavily compress the SVG data - there are literally tons of redundancy, you could probably achieve compression by 20 times easily in most case (that's only random guess out of my head). There can be specific format defined for such a case (SVG NFT) - I can see it being heavily used in case that NFT creators wan't to draw vector images 
NIt will be really big advantage over the traditional NFTs, where have you rely on centralized hosting or unstable decentralized IPFS (if you don't own the IPFS servers itself in order to make sure the 100% time availability)... So having such a fully on-chain vector images NFT standard would be awesome 
N---
N@Foeniculum are you making your NFTs in some vector editor or not?
Kchecking
K@nitram147 fixed, explorer is catching up, but I guess I need to release new 5.0.0-RC2 testnet node version with 4.0.35 merged
NWhat was causing the problem? 
K=======================
The weekly Ergo Developers chat will take place here tomorrow, Wednesday, July 27th, 1PM UTC.
@Ecosystem Core @Community Developer
The weekly Ergo Developers chat will take place here tomorrow, Wednesday, July 27th, 1PM UTC.
@Ecosystem Core @Community Developer
Fall hand drawn with full pen pressure over vectors
Fit's to give characters more depth and make them more "alive", as vectors tend to flatten things out (and changing the thickness of the vectors manually still doesn't achieve the same "natural" effect of pure pen pressure imo!)
NSo are they vector or not? Which program are you using? In which extension are the raw full quality NFTs saved? 
Fthey're not vectors, they're... pen strokes drawn by hand 
FI'm using Paint Tool SAI with a Wacom Intuos
Ffull quality NFTs (2000x2000 pixel) saved in .png
Fresolution is 300 pixel/inch
NI wanted to see size of that file if it was made as an vector - but as you have mentioned probably vector versions of your NFT wouldn't be so much pretty. I was curious whether we can find such a way that the whole complex looking (e.g. such ergnomes looks like) picture could be fully stored in it's vector format on-chain inside of NFT metadata...
NBut since you are not drawing them in a vector format, than there's no such a discussion
LThere are chains that can do that type of thing natively, but as far as I know Ergo is not one of them.
MErgo logo as svg ~ 1 Kb (or other crypto logo)
Mso only very-very-very simply svgs can be stored on-chain
Malready exist compressed svg format - svgz 
NThat's not an effective compression
NIt's compressing it with text compression algorithms
NMost of the SVG text is representation of number which can be each encoded as one byte (in best case) or more bytes via variable length coding
NThis would be much more efficient than the current SVGZ implementation
Myep, someone can use 7z (or smth), but this "svg-7z" will be manually maintained on 1-2 sites
Meven svgz does not work everywhere
NYou are still talking about general compression algorithms but that's not the case. In case that there will be a demand for it, we can develop SVG specific compression algorithm with even "bit precision" (meaning that we will be saving even bits not only bytes, whenever it's possible) which can achieve highest possible compression factor compared to general approaches.
NThat compressed SVG from chain shouldn't be "shown" in the browser. It would firstly decompressed by the same javascript which has retrieved it from the chain and only than showed to the user via standard xml SVG format which is supported natively in the browser
NErgo logo could be probably compressed to around 200 bytes, so assuming we can have 24kB NFTs, there can be 100 times more complex picture than the current ergoplatfomr.org logo
WErgo Community Forum
Continuing old idea of “smart orders” (see DEX orders with buyback guarantee, smart-order based DEXes , New Ergo Smart DEX Orders with buyback guarantees | Ergo Platform ) , we can do decentralized grid trading on Ergo (which is automatically compatible with existing DEXes, such as ErgoDEX LP pools and babel fees). Grid trading is a good way to ...
Mdev.w3.org/SVG/tools/svgweb/samples/svg-files/tiger.svg 96 Kb ... 7z-zipped --> 26Kb
I think that complex vector files will not have such a large compression ratio (100x)
I think that complex vector files will not have such a large compression ratio (100x)
WWhy put files on the blockchain, I guess hash is enough in such case. You need to store a file if it can be used after on chain, so in some contract.
MYes, I thought about it a year ago. But we need @anon_real and @Hazey to implement it in the auction house and skyharbor. For now I made some ugly 
on-chain "tokenart" tokens (with only 1 buyer) with "ASCII art" in description field (not fully supported in AH and SH).
on-chain "tokenart" tokens (with only 1 buyer) with "ASCII art" in description field (not fully supported in AH and SH).