RE: A witness update: 2nd quarter
I absolutely love the direction you're going, Jesta! This is the foundations of the future, and it's beautiful to see it coming together.
When I read this:
I'm sick of repeating myself - so I'm making one more wheel, but plan on reusing it wherever possible.
I couldn't help but think of this:
Heheh. Seriously though, what you're doing is important and needs to happen.
Related to "Anchor (key storage)", have you looked at what Edge Wallet is doing? I think more people using a consistent, recoverable, user-friendly approach to secure key management will help the whole industry.
For "Anchor (defining uri scheme)", are you going to create a formal RFC to piggy back off of RFC-5988? I think that would be really be helpful.
Also, for the API endpoints and surface you're building, have you considered going with a true hypermedia/REST approach? One of the problems (IMO) with the graphene family is the reliance on RPC. Most documentation systems for APIs assume people are doing a REST (ish) approach over RPC at this point. Curious what you think about that.
Keep being awesome, man. You've created more value for this space than most everyone else combined and we all really appreciate the tools you've built, and will continue to build in the future.
LOL, yeah... that comic definitely hits on multiple levels of truth.
I don't think I have looked at Edge Wallet yet - though after briefly looking at the page it looks like I've got more research to do lol. Thanks for the tip!
In reference to the URI scheme - I haven't make any decisions there, but it feels like that would be the proper way to go about it. My biggest hesitation to get really deep "formal" stuff is just a lack of experience doing so. At this point I have a pretty solid idea of how it should work, and how it should be implemented, but communicating that through a documented formal standard is something I'd have to really learn to do.
As for the APIs - yeah, I agree with the reliance on RPCs being an issue, and they most certainly will end up being rest APIs. I haven't even considered those kinds of features for this yet, but I don't see why it couldn't have HATEOAS or some newer standard applied to it. The last real consumer focused API I worked implemented it (which you can see in the docs) - so that shouldn't be too hard to remember how to do!