Proposal: Developer Tools Roadmap Q1+Q2 2019

#1

Hey everyone,

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.

    1. 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.
    2. Alternate implementations of Blockstack authenticators/browsers
    3. 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.

  • Consistent and improved error handling

  • Improved tests

Proposal: Chat provider for Inbox/Notifications
2018-12-12 Engineering Meeting
#2

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.

#3

Thank @yukan

+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!

#4

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.

Uniqueness

#5

Amazing list.

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?

#6

@yukan Thanks for sharing the list.

My vote is for Collections.

#7

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.

#8

100% agree with this priority list.

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.

#9

I desperately need notifications for my app going to implement them on day one if it’s possible :joy:

#10

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.

putFile('file.json', myFile, {encryptForUser: 'anotherUser.id'})

That would be awesome to see!

#11

Cool. I will contact you for this soon (busy with another project atm).

#12

+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.

#13

I would like to see improvements of the proofs in the direction of verifiable claims (https://w3c.github.io/vc-data-model/).

#14

That would include for one other user. For a group of users that would then be a collection, I guess.

#15

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!

#16

Adding another proposed item here:

Large file support

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.

#17
#18

Sorry for the late response.+100 to this @yukan

#19

Great list @yukan!

My top requests, in order are:

  1. Move ID creation and profile logic from browser to blockstack.js + enabling burner IDs
  2. Inboxes/Notifications
  3. Large file support (thanks @larry)