search

status-im / specs

Specifications for Status clients.
https://specs.status.im/
MIT License
14 stars 14 forks source link

Document specific EIPs supported #6

Closed oskarth closed 4 years ago

oskarth commented 5 years ago

To avoid situations like this: https://discuss.status.im/t/sending-limit-per-contact/1179/6?u=oskarth

And make it clear which once we support and not.

Also see LES etc.

This is more of an INFORMATIONAL one for each client (status-go, Status App), but really useful to have at a glance.

oskarth commented 5 years ago

cc @status-im/clojure

oskarth commented 4 years ago

^ @andremedeiros @yenda @flexsurfer @corpetty @rachel fyi, would love to this documented, even in just a basic form. rachelhamlin

oskarth commented 4 years ago

https://notes.status.im/h_so7p_4T3WK0aTytRX1YA# this one by @3esmit is an amazing start! Would love to see it as a PR to this repo

3esmit commented 4 years ago

@oskarth I will happy in help documenting all EIPs supported by Status.

The notes you linked are respective only to Status-React, which mostly envolve stuff related to wallet and dapp browser, but not related to status/whisper protocol (as this is part of status-go) or to ethereum/blockchain consensus.

There is almost an EIP to every detail on ethereum, which is awesome, but can make this list over extensive.

How do you think we should organize this EIPs list? Perhaps a table with filters would be great?

Should we separate status-go EIPs from status-react EIPs, or this should be simply a field in the table?

rachelhamlin commented 4 years ago

Perhaps two tables in the same doc? If doc week becomes a thing, we could work on improving the information architecture then.

oskarth commented 4 years ago

Good points, I don't know. Whatever is easiest for now, and then we can go from there? Perhaps it makes sense to separate EIPs and ERCs. I'm not convinced separating status-go and status-react makes sense, this seems more like an implementation detail, but I could be wrong.

The notes you linked are respective only to Status-React, which mostly envolve stuff related to wallet and dapp browser, but not related to status/whisper protocol (as this is part of status-go) or to ethereum/blockchain consensus.

A lot of this is documented in specs already.

Also cc @adambabik @decanus for thoughts

oskarth commented 4 years ago

@3esmit what do you think of just adding above HackMD as PR? We can iterate later, but it'd be good to capture it in specs repo.

3esmit commented 4 years ago

Fine, I can PR it.

Questions:

  1. Include in the list "under consideration" (which is in this list because one or more Status.im contributors mentioned it)? Or keep the list strictly to what is already implemented?
  2. The format I am using is OK or there is anything I should improve? Do you want me to copy other example/template?
oskarth commented 4 years ago

Thanks!

  1. Only things that are actually in implemented IMO, then we can have issues in specs to get more EIPs part of it
  2. Format seems fine for now, can tweak later. For template, can use basic one that exists in current specs e.g. https://raw.githubusercontent.com/status-im/specs/master/status-client-spec.md but no need to go overboard

cc @corpetty

Then for document week we can figure out how to improve it (@rachelhamlin @andremedeiros fyi)

rachelhamlin commented 4 years ago

I appreciate that doc week is a thing now. :) Soliciting more feedback and buy-in on that now.