Might make sense to port https://github.com/zxing to Go? Seems a popular library and I think it was created by Google folks.
On Tuesday, December 26, 2017 at 11:29:44 AM UTC-5, Frank Davidson wrote: > > I'm not sure we could encrypt codes for them as we would not have their > private key? I think we could provide an CLI executable that could make it > really easy, though. on virtually any OS (the benefits of Go!)... > > Also, I agree on the advertising but it's not a deal breaker for me if > they did. I think that the ability of the manufacturer to provide > additional info about that bottle, e.g., expiration date, place of > manufacture, counter indicators and drug interactions, user instructions > and self-help videos, etc., would be quite useful and beneficial to the end > users? > > I'm not sure why we would need to involve distributors? Maybe you can > explain that idea more? If the code is on the bottle, how would it matter > what distributor delivers it, assuming it's a somewhat tamper-proof bottle? > > Cheers! > > Frank > > On Tuesday, December 26, 2017 at 11:03:22 AM UTC-5, matthe...@gmail.com > wrote: >> >> For implementation I’m of the opinion that we should own everything >> besides printing the labels. There is only the one path of data between the >> consumer and our server+database in a cloud center. We nor the >> manufacturers should be able to advertise to consumers through this, and >> consumers should be able to understand the barcode no matter what chain got >> it to them. We have to build consumer trust for these barcodes to matter. >> >> I live in the USA, but the report centers around Kenya. If we’re not >> talking about one government then handling regulation is a key and large >> part of this project. If we’re working in more than one country we’ll need >> to have language translation done. I still think we need a connected >> partner organization that's done such things before. >> >> Even the manufacturers and distributors may have a limited connection to >> our servers. What kind of operating systems are these people using to print >> labels? We can’t be a manufacturing bottleneck, so perhaps we’d need to >> provide blocks of barcodes instead of individually requested ones. Perhaps >> a worker goes somewhere else and walks in a drive with the barcodes. >> >> That barcode library seems not done - we’ll probably need to support our >> own. I assume this will be open source and those using the system will want >> to review the code. >> >> Here’s my take on the process: >> >> 1. Manufacturer asks us for a barcode block targeting a distributor for a >> product >> 2. We generate that number of PNG barcodes containing individual UUIDs >> that in our database is matched to a product ID, manufacturer ID, and >> distributor ID >> 3. Manufacturer downloads the block and applies the images to their label >> printing process >> 4. Distributor scans a subset of these barcodes and for each sends us a >> verification request with the scanned UUID and the three IDs independently >> provided >> 5. We mark each as distributor scanned in our database, and now we know a >> block has at least some scanned, or we indicate to the distributor that >> there’s a problem >> 6. Distributor distributes product with original manufacturer’s barcode >> intact, scanned or not >> 7. Consumer uses our app to scan the barcode, and we then tell them if >> the distributor verified part of the block, if it has been previously >> scanned by a consumer, who the distributor is, what the expected product >> is, and who made it, all of which can be compared to the label. >> >> Matt >> >> On Tuesday, December 26, 2017 at 9:00:17 AM UTC-6, Frank Davidson wrote: >>> >>> Yes, that's the Aztec library I saw for creating the codes. Looking now >>> for a good OS library for reading them... >>> >>> I'm thinking the sequence would go something like this: >>> >>> >>> 1. Manufacturer creates key pair >>> 2. They register their public key with our central server >>> 3. The public key is posted on a URL REST endpoint on their >>> certified domain >>> 4. They download our code/library which enables them to create >>> unique Aztec codes at manufacturing speed signed with their public key >>> 5. The Aztec code payload would be JSON containing the above >>> mentioned URL, by default a UUID, and any other metadata they would have >>> the space to include. The payload would be signed with their ECDSA >>> signature. >>> 6. That unique Aztec code gets, ideally, printed on an individual >>> bottle but could also maybe be code for a shipment or pallet or some >>> other >>> grouping if individual bottles are cost prohibitive for some >>> manufacturers >>> 7. An individual or small pharmacy upon receipt of the drugs would >>> scan the Aztec code in our "App" or website >>> 8. If the signature checks out they are forwarded to the URL in the >>> JSON payload >>> 9. The cert of the domain is verified >>> 10. The rest of the JSON payload is relayed to the manufacturer. >>> 11. The manufacturer can then track the individual bottle and/or >>> offer other info/services to the individual user. >>> >>> Thoughts, comments, and criticisms welcome! >>> >>> Frank >>> >>> >>> On Monday, December 25, 2017 at 4:46:49 PM UTC-5, Tamás Gulácsi wrote: >>>> >>>> https://github.com/boombuler/barcode is a MIT licensed Aztec code >>>> generator. >>>> >>>> You'll have to become a trusted central authority for the drug >>>> companies - or at least provide the infrastructure for the government to >>>> force such a central registry for uuids and public keys. >>>> >>>> I think here the technical solution is almost ready, you have to >>>> assemble already existing components. The bigger problem is to build the >>>> concept and make a lot of important people accept it. >>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
