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?
