2018-11-12 Engineering Meeting


#1

Date/Time: 2018-11-12 @ 15:00 UTC / 10:00 EDT / 23:00 HKT
Click here to convert to your time zone
Length: 45 minutes
Meeting link: [https://zoom.us/j/966890423]

This meeting is for the engineering team, app developers and the community to discuss engineering concerns or questions.

Agenda

Please reply to this forum post with items you would like included on the agenda.

Each item should include:

Item name
Background information: Links to github issues, forum posts, etc with background information on the item
Desired outcome: what decision or deliverable would you like from the discussion of this topic at the meeting?

Minutes

  • Thomas is working on a UI component library for Blockstack applications

  • What is the status for the GAI admin sidecar UI. Might be a question for @markmhendrickson. Discussion about how that might be implemented. Administrating is currently painful as you have to SSH. @jude is going to write up some tips for how the project might be built and we will post to the community on the forum. See if anyone wants to build one.

Safari / Firefox on desktop Protocol Handler issue (@larry)


We can’t detect reliably custom protocol support. If you don’t have the local browser installed on the system can’t redirect to our web browser. The web browser can’t tell if the local browser is installed or not.

Redirects all browsers on mobile to Chrome ---- we did not implement this on the Desktop. We punted it and put it together with the future roadmap of the “browser.” Recap, the current browser name is confusing. So, we had planned to do this with a new edition of that.

@jeffd and @aulneau.id went back into roadmap history. The idea is that we planned to fix this with work that is planned but not resourced. @larry entered into the discussion and some talk about the roadmap for his new project which will leverage the direction of what our Blockstack Eng team is doing.

@yukan said we should set it to always go to the web browser. Then in the browser we can check if they are on one of the browsers that supports local. Then, we can check if they have local and redirect to local. @aulneau.id it would be nice to offer a flag to check.

@jeffd Is there some way we can detect where the request originates native or local?

@larry discussed an architecture that would allow us to do this. If you have downloaded our Blockstack for Mac, our local browser does work with Safari.

If you don’t have the native app and you are on Safari, the web browser redirect fails with a protocol error.

@hank pending more form factor changes, we could do something clever to detect if the user is still on the page, on Safari we could do some sort of timeout. If they hit timeout…@larry that is what the solution is now and it isn’t working. You either get an error or you never navigate away from the page…@hank the way it works today the protocol check doesn’t work…overlapping voices.

@aaron if you always redirect to browser.blockstack.org (@yukan suggestion) . There it will attempt to load the protocol handler. Either nothing happens or it loads. Overlapping voices.

@larry We used to have that behavior. We were ending up opening both the auth.

@hank Now is leaning toward a very simple Chrome extension that would likely work for everything.

@jeffd Says doesn’t this make a problem for the developer user as it adds in more steps in the onboarding.

@larry Basically, I think this is why we need an actual browser. We are trying to use today’s browser for the new things we are trying to do. That’s why I think the solution is a standalone browser. Right now, there is a high cost to get in with the current API.

@jeffd If you are not in the native browser, everything just sends to the native browser. In the build the for the browser, we just override the code to load in the users currrent client.

@larry Explains the issue regarding the native browser/developer needs/ and need to update.

Team further discussions of how to solve this problem or implement.

@aulneau.id API exposed in the browser…@larry start to run into CORs issue. They really locked down web

@shreyas floated the idea of an authentication API . Discussion of this went down about how that start to lead to how unsecure this kind of solution can be.

Seeds and stealing them and other problems with this approach discussed.

Envelopes impressed lots!

Rough plan for auth protocol: Pop up a window that offers a choice — do you have the native browser installed?


#2

What is the status for the GAI admin sidecar UI. Might be a question for @markmhendrickson. Discussion about how that might be implemented.

Tomorrow I expect we should gain clarity on team formation around the Gaia work this quarter, then we should be able to advance quickly to producing designs for this UI. I’d personally love to sync up about the sidecar work early next week to start thinking through the design considerations. I’ll follow up here about next steps by this Friday.


#3

@markmhendrickson We agreed that this sidecar might be a perfect project to ask the community to build. @jude and @jwiley thinks that is entirely doable. That would give a cool project to the community and offload our resources to do other things. Jude was going to write up a bit of a project brief we could put out there. Open source, the old school decentralization.

Discuss amongst yourselves.


#4

Tried sharing the brief via Graphite: https://app.graphitedocs.com/documents/doc/1542211711301 I think I guessed your blockstack IDs correctly, but let me know if not.

EDIT: use this link: https://app.graphitedocs.com/shared/docs/dweb2018.id.blockstack-1542211711301 Thanks @jehunter5811!


#5

Hey look at that! Though that’s not the share link :frowning:

I just realized on the new design, the share link is not displayed after sharing. Working on a fix for that, but the link would be:

https://app.graphitedocs.com/documents/single/shared/jude.id/1542211711301

Replace jude.id with the correct ID you were sharing from, Jude.


#6

Here’s a discussion about desktop browser auth. Please comment: Proposed solutions for desktop safari & firefox sign in


#7

I like that idea of asking the community! How do we want to go about that? Post to the forum our project brief and request submissions by X date?

Also, I think I’ve already seen some dev activity on the sidecar in GitHub within PBC – would this community contribution be limited to the web UI or concerning the whole sidecar?

cc @jude @jwiley


#8

The plan was after @jude writes it up a brief, done, thanks Jude! We would post to the forum. We can link to the written brief on Graphite — why not? From the forum post we can post some picks of “ideas” and link to the component Kit that @aulneau.id is building. That way we get a twofer. The component kit would give devs and easy way to get a recommended look and feel also.

We should also promote it a bit maybe on Slack and Twitter.