Generating QR codes for sharing

28 views
Skip to first unread message

Troy Farrell

unread,
Jan 25, 2021, 11:57:27 PM1/25/21
to Sandstorm Development
Now that I have the option to adding a path and a hash to URLs for sharing, some of my users would like to have a QR code generated for the URL.  I'd like to collect your thoughts on how we might do this.

The QR code could be generated on the server or on the client.  I don't think that it matters to me.

Some QR codes contain a URL and other information.  A grain could provide that information with an API like the renderTemplate postMessage API.

The startSharing postMessage API does not currently provide any feedback (like a proper RPC would) to the caller, so this might not be the best call to extend.  (Aside: we might consider deprecating startSharing in favor of a call that does report errors.)

What other considerations do you see?

Thanks,
Troy

Ian Denhardt

unread,
Jan 26, 2021, 12:11:28 AM1/26/21
to Sandstorm Development, Troy Farrell
I see two cases:

1. You want to use the sharing dialog (either with startSharing or via
the user clicking share themselves).
2. You want to supply an API link, like you would an offer iframe.

For case (1), perhaps we could just add another tab to the sharing
dialog that renders the link as a QR code, no API changes necessary.

For case (2), I think extending the offer iframe mechanism to allow
rendering as a QR code would make sense. This could be as simple as an
optional `qr: true` option, which would render the template as a QR code
rather than text.

Re: error reporting in startSharing: are there errors that can happen
for reasons other than incorrect use of the API? If not, I don't think
it makes sense to bother expanding the API surface just to report errors
to a buggy app (as opposed to just logging them to the browser console).

-Ian

Quoting Troy Farrell (2021-01-25 23:57:27)
> --
> You received this message because you are subscribed to the Google
> Groups "Sandstorm Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [1]sandstorm-de...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/sandstorm-dev/3fd977d4-2236-4f05-b
> f5b-c57b198e2364n%40googlegroups.com.
>
> Verweise
>
> 1. mailto:sandstorm-de...@googlegroups.com
> 2. https://groups.google.com/d/msgid/sandstorm-dev/3fd977d4-2236-4f05-bf5b-c57b198e2364n%40googlegroups.com?utm_medium=email&utm_source=footer

Troy Farrell

unread,
Jan 26, 2021, 12:33:12 PM1/26/21
to Sandstorm Development
On Tuesday, January 26, 2021 at 12:11:28 AM UTC-5 Ian wrote:
I see two cases:

1. You want to use the sharing dialog (either with startSharing or via
the user clicking share themselves).
2. You want to supply an API link, like you would an offer iframe.

For case (1), perhaps we could just add another tab to the sharing
dialog that renders the link as a QR code, no API changes necessary.

Yes, I think that an additional tab would be a good first pass.  Better still might be something like the widget implemented at send.vis.ee.  It has a link with a QR code button.  Clicking the button provides a larger version of the QR code for scanning.
 
For case (2), I think extending the offer iframe mechanism to allow
rendering as a QR code would make sense. This could be as simple as an
optional `qr: true` option, which would render the template as a QR code
rather than text.

Yes, we could extend the offer iframe to do this.  I like this option.  I might use this option, even if I only wanted to share a URL, because the presentation could be better.
 
Re: error reporting in startSharing: are there errors that can happen
for reasons other than incorrect use of the API? If not, I don't think
it makes sense to bother expanding the API surface just to report errors
to a buggy app (as opposed to just logging them to the browser console).

There's a call to newApiToken at grain-client.js:520 which could possibly fail.  Failure logs the error to the console.  I don't think that a grain could do anything about it, but that's a failure that could be reported back to the grain.  It would at least know that the sharing didn't work.
Screen Shot 2021-01-26 at 12.27.10.png

Troy Farrell

unread,
Jan 26, 2021, 12:48:51 PM1/26/21
to Sandstorm Development
A few more thoughts before I take a first pass at this:
1. Client-side or server-side?  I think client-side rendering makes more sense.
2. All other things being equal, I prefer a library that renders the QR code as SVG over, e.g., rendering on a canvas element.
3. Is there a specific QR code library that we should prefer?  One with Meteor support?  One with TypeScript support?  One that has only the features we need an no more, to limit the potential attack surface?

Thanks!
Troy

Ian Denhardt

unread,
Jan 26, 2021, 6:17:12 PM1/26/21
to Sandstorm Development, Troy Farrell
Quoting Troy Farrell (2021-01-26 12:48:51)

> I think client-side rendering makes more sense.

Agree.

> All other things being equal, I prefer a library that renders the
> QR code as SVG over, e.g., rendering on a canvas element.

Agree.

> 3. Is there a specific QR code library that we should prefer? One
> with Meteor support? One with TypeScript support? One that has only
> the features we need an no more, to limit the potential attack
> surface?

I don't know what's out there off-hand, so can't point to specific
libraries. I would favor something simple with a minimal dependency
footprint.

Happy Hacking,

-Ian

Ian Denhardt

unread,
Jan 27, 2021, 4:40:54 PM1/27/21
to Sandstorm Development, Troy Farrell
Quoting Troy Farrell (2021-01-26 12:33:12)

> There's a call to newApiToken at grain-client.js:520 which could
> possibly fail. Failure logs the error to the console. I don't think
> that a grain could do anything about it, but that's a failure that
> could be reported back to the grain. It would at least know that the
> sharing didn't work.

I wouldn't object to adding some code to send the error back to the
caller then.

-Ian

Troy Farrell

unread,
Jan 27, 2021, 9:55:17 PM1/27/21
to Sandstorm Development
If the (startSharing postMessage) caller provides an rpcId, the method could use postMessage to return a status, whether an error or a success.  This would be a backward compatible solution, which would convert the startSharing postMessage into a proper RPC call.  I don't know if I would consider it a change to the current call or a parallel implementation of a new call that has the same name.  I don't know if this is better or worse than implementing a completely new call.

Ian Denhardt

unread,
Jan 27, 2021, 10:25:19 PM1/27/21
to Sandstorm Development, Troy Farrell
I'd just add this to the existing call.

Quoting Troy Farrell (2021-01-27 21:55:17)
> --
> You received this message because you are subscribed to the Google
> Groups "Sandstorm Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [1]sandstorm-de...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/sandstorm-dev/7821720b-cebb-49f0-a
> 9c2-9f19d9f4769bn%40googlegroups.com.
>
> Verweise
>
> 1. mailto:sandstorm-de...@googlegroups.com
> 2. https://groups.google.com/d/msgid/sandstorm-dev/7821720b-cebb-49f0-a9c2-9f19d9f4769bn%40googlegroups.com?utm_medium=email&utm_source=footer

Troy Farrell

unread,
Jan 28, 2021, 10:50:55 PM1/28/21
to Sandstorm Development
On Wednesday, January 27, 2021 at 10:25:19 PM UTC-5 Ian wrote:
I'd just add this to the existing call.
 
Issue created for startSharing postMessage error handling: https://github.com/sandstorm-io/sandstorm/issues/3496

Troy Farrell

unread,
Feb 1, 2021, 11:32:26 PM2/1/21
to Sandstorm Development
On Tuesday, January 26, 2021 at 6:17:12 PM UTC-5 Ian wrote:
I don't know what's out there off-hand, so can't point to specific
libraries. I would favor something simple with a minimal dependency
footprint.

I am evaluating this QR code generator library:


It has about 1000 lines of readable TypeScript, uses an MIT-style license and generates SVGs.

Jacob Weisz

unread,
Feb 1, 2021, 11:56:16 PM2/1/21
to sandst...@googlegroups.com
While I probably can't evaluate the library itself, the author seems to be a pretty insightful developer based on blog posts. I have a new feed in my TTRSS at minimum.

--
  Jacob Weisz

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.

Ian Denhardt

unread,
Feb 3, 2021, 9:20:36 AM2/3/21
to Sandstorm Development, Troy Farrell
Looks like a reasonable choice to me!

Quoting Troy Farrell (2021-02-01 23:32:26)
> --
> You received this message because you are subscribed to the Google
> Groups "Sandstorm Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [1]sandstorm-de...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/sandstorm-dev/97693729-68ff-4499-a
> 107-8385e8cf9889n%40googlegroups.com.
>
> Verweise
>
> 1. mailto:sandstorm-de...@googlegroups.com
> 2. https://groups.google.com/d/msgid/sandstorm-dev/97693729-68ff-4499-a107-8385e8cf9889n%40googlegroups.com?utm_medium=email&utm_source=footer
Reply all
Reply to author
Forward
0 new messages