I wanted to gather your input for the developer tools roadmap in 2019. Essentially the features and improvements to the Blockstack dev tools (including blockstack.js, iOS and Android SDKs) that we should prioritize in 2019 Q1 + Q2.
Below is my list. Please add to it or let us know why we shouldn’t work on something. Keep in mind that this is a proposal and we might not end up working on everything proposed.
Inboxes/Notifications
Any app that has user to user interaction needs a signalling protocol. This is a challenge in decentralized apps. Many apps currently work around this and we lack an officially supported and reliable method.
Collections
This allows users to bring their data to different apps via shared schemas. For example, as a user I can have a single photos collection that I can bring to different photo apps and messaging apps.
Split blockstack.js into scoped packages
The library is starting to become bloated as we continue to add features. And we might be moving more logic from the browser and else where into the library. It would make sense to split the library into scoped packages. i.e. @blockstack/auth, @blockstack/stacks, @blockstack/id
Move ID creation and profile logic from browser to blockstack.js + enabling burner IDs
By moving some of the logic currently in the browser into the library, we enable several things.
Burner IDs - let apps generate keys and register names for new users with the expectation that they will eventually move them to a more secure user generated ID from an authenticator app. This has the potentially of greatly simplifying user onboarding.
Alternate implementations of Blockstack authenticators/browsers
Other creative uses by developers
Encrypting data for other users
Natively supported encrypting files for another user through getFile and putFile.
Improve or remove social proof verifications?
Social proofs in the browser are a little bit finicky right now. We should either find a way to improve them or get rid of them.
Blockstack React HOC’s for auth
This is probably something that would be nice to have for React development. A higher order component that wraps the router and renders different pages based on the authentication status.
BNS resolution of websites and apps
The ability to register and resolve ID’s that point to an app or website. Again this has been talked about a lot in the past and has the potential to open a lot of doors.
This is a great list @yukan - I’m very excited about it, particularly collections, the ability to easily encrypt data for other users and inboxes. I think app developers will find lots of great uses for these features.
I’m also excited about the developer experience improvement related items on the list.
It might make sense to spin social proofs off into its own library and leave that to the community. It’s unclear how any apps are using it
The React HOCs also seem like a great project for someone in the community that wants to get involved.
+1 on Inboxes/Notifications
Blockusign could use this to share a doc to sign instead of a link or email.
+1 on Collections
Would make pulling in data from other apps easier. Especially document apps like Graphite
And please improve and keep social proofs! In Blockusign, I want to use these attestations to link a blockstack id to a real person, which is important for a Digital Notary Service, to prove two real humans signed something!
It would be nice if social proofs were “pluggable” or customizable. There is another community member building a reputation system that sounds more powerful than chasing various centralized social networks.
Isn’t this already possible? You can do encryptContent with another user’s publicKey and then putFile. Is this about reducing it to 1 step instead of 2?
I am new in the community but from what I have read and understood so far here are my thoughts. Please pardon me if something does not make sense.
I would put Notifications as the highest priority for the official team to work on. Two reasons - apps will keep making their own standard if it is not officially decided, notifications are a very important feature for data-based apps.
Collections - Would be a nice to have but I guess it won’t hurt to delay it and give apps some time to develop (more).
blockstack.js - Nice to have but not a must.
React HOC - Should be a good community project. In fact, I would like to do it.
Apps manage notifications in a relatively centralized way now because there’s not a good decentralized alternative. If Blockstack has a way to help facilitate this, that is absolutely my vote for the top priority.
The problem with the way we’re currently doing social proofs is that it’s very brittle and any changes on the website of the social network could break the proof verification. We either need to find a new solution or have community members step in and help with updating the library.
Yes, we want to make it so that you can encrypt for someone using just their username. Key management would be handled by the library.
+1 for this. This is at the core of blockstack decentralized storage and helps developers to create a better ecosystem (instead of duplicating data). You can learn e.g. from the Android content provider contracts for
contacts
calendar
media store
I like to see schema.org definitions for common collections and definitions in the same schema definition for more app specific collections.
-1 for this. I think this should be solved by an existing (or under development) protocol. matrix.org or apache wave comes to mind.
For matrix, a room per app could be created, the user could define the matrix host like she does for gaia storage. Once, matrix sorted out their identity server this could even be the same on blockstack and matrix.
-1 for this. I don’t see how a HOC could be beneficial. We should educate developers how to use blockstack in such a way that it does not get in the way in the UI. blockstack.js should only be required in middleware.
Encrypting data for multiple users wouldn’t necessarily be a collection. I see a collection as some structured data that conforms to a known schema that has permissioned access usable by multiple apps.
We’d want to discuss how encryption for multiple users works since there are a number of approaches that might work.
Really like @friedger 's suggestion that we look toward using existing standards/projects whenever possible!
We’ve implemented a file size cap in the default gaia hub run by Blockstack PBC that acts as a de facto max file size that apps can store. We’ve also had developers report weird behavior and crashes in our encryption routines for larger files: https://github.com/blockstack/blockstack.js/issues/536
I propose having a clear story and support for larger files at least as large as those commonly supported by commodity cloud storage backends.
