Add label to address about etheraddresslookup HOT 10 CLOSED

I've been working on this issue in this branch : https://github.com/409H/EtherAddressLookup/compare/master...Samyoul:issue/4?expand=1

I've set up a storage class that can change the context of where to store data, so you can use local or you can use sync.

I've come to a point where we can implement labels in a couple of ways.

My Current Approach :

• Sort of easy to follow data structure
• sort of ok storage efficiency
• great for matching previously stored addresses.

Labels are created and stored on the address level and can be assigned on an adhoc basis. But for common labels the user will need to manually create these each time.

storage = {
    0x123: {
        labels: [
            ['jeff', 'eaeaea'],
            ['contributions', 'dadada'],
            ...
        ]
    }
    0x321: {
        labels: [
            ['bob', 'bbbbbb'],
            ['contributions', 'dadada'],
            ...
        ]
    }
    ...
}

Another Approach (possibly better):

• storage efficient (there is probably a better way)
• not bad for matching previously stored addresses
• a bit obtuse data structure

Labels are created first and then assigned to an address.

storage = {
    labels: [
        ['jeff', 'eaeaea'],
        ['contributions', 'dadada'],
        ['bob', 'bbbbbb'],
        ...
    ],
    0x123: {
        labels: [0,1]
    },
    0x321: {
        labels: [2,1]
    },
    ...
}

Alternative of the same thing

storage = {
    labels: [
        ['jeff', 'eaeaea'],
        ['contributions', 'dadada'],
        ['bob', 'bbbbbb'],
        ...
    ]
    addresses: [
        0x123: {
            labels: [0,1]
        },
        0x321: {
            labels: [2,1]
        },
        ...
    ]
}

Another Approach (probably not better):

• Really clear human readable data structure
• terrible for matching with previously stored addresses
• not storage efficient.

Labels are created first and then addresses are assigned to them.

storage = {
    labels: [
        {
            name: 'jeff',
            colour: 'eaeaea'
            addresses: [
                '0x123'
            ]
        },
        {
            name: 'contributions',
            colour: 'dadada'
            addresses: [
                '0x123', '0x321'
            ]
        },
        {
            name: 'bob',
            colour: 'bbbbbb'
            addresses: [
                '0x321'
            ]
        },
        ...
    ]
}

Which way do you favour? Do you have another method to consider?

from etheraddresslookup.

Yeah, have a play around with the branch.

Skype call will be fine, we can message on Twitter/Skype about it.

The one big downside in my mind, from a UX point of view, with my current approach is that users won't be able to create pre-existing labels to quickly assign to an address. Something like dev, bug bounty, tip jar, SCAM!! etc.

We could give them some presets, but the user will have to manually create all other labels every time they want to assign them to an address.

We could save the labels as shown in Another Approach (possibly better):, preload the labels everytime and keep them in memory and then call them as needed. The potential downside is if a user has 1000s of labels it may affect the performance. Get from storage is an async function so labels won't show until all are loaded.

We could limit the number of labels, might tick some people off. Or we could allow the user to create a limited number of "saved labels" for easy assignment and set the limit at 500. High enough most won't use them, but low enough that it won't affect performance.

If we did that then we could have a structure like below:

storage = {
    labels: [
        ['SCAM !!!', 'eaeaea'],
        ['tip jar', 'dadada'],
        ['dev', 'bbbbbb'],
        ...
    ],
    0x123: {
        labels: [
            1,
            ['Jeff','a3def1']
        ]
    },
    0x321: {
        labels: [2,1]
    },
    0xdef: {
        labels: [0]
    },
    ...
}

Then in the JS we add check if the label elements are integer or array:

for(var i = 0; i < labels.length; i++) {
    //is the value an integer
    if(Math.round(labels[i]) === labels[i]){
        // Do lookup logic to make label
    }
    else{
        // Do label creation from data in this array
    }
}

from etheraddresslookup.

Things still to do

• Add label styling
• Implement native JS popover functionality
• Implement native JS tab functionality
• Add popover styling
• Add tab styling
• Create Chrome Storage abstraction class
• Create Label extension of Storage class
• Create Address extension of Storage class
• Create quick label structure
• Implement quick label creation UI
• Implement quick label retrieval and population of UI
• Quick label delete functionality
• Quick label edit functionality
• Add quick label select to address popover
• Assign quick labels to addresses
• Populate address popover with given labels
• Complete ad-hoc label creation UI
• Test quick label and ad-hoc label retrieval and presentation

from etheraddresslookup.

I missed this last month, but Chrome Storage has the added benefit of syncing across devices. 🎉

from etheraddresslookup.

Hey @tayvano , yeah this is the main reason I've suggested Sync storage over local. It'll make the extension a lot more user friendly, and behave more as users expect.

from etheraddresslookup.

@409H Do you imagine this to be handled by https://developer.chrome.com/extensions/storage ?

from etheraddresslookup.

Yeah, I was looking at that - or just localstorage from the extension and send it to the DOM like I've done with the other stuff

from etheraddresslookup.

Very interesting!

I quite like the idea of using the address as the index (your current approach). Having fast matching on the address is key to this IMO, so your approach best-fits right now. I'll have a play with your branch tonight.

Perhaps we could do a video call and talk about all these things you're bringing to EAL.

from etheraddresslookup.

@tayvano @409H @Samyoul
Please let me know if pull request #602 addresses your needs. There's a video there which shows how this feature works.

from etheraddresslookup.

@kuzirashi Thanks for the PR.
The video illustrates it well, thanks for your time and effort on this!
I'll review and test and will get back to you with anything

Please can you also DM me on Twitter [@]sniko_

from etheraddresslookup.