![](https://media.kbin.social/media/2f/a9/2fa9b5a4da1a8ee794dd1c5e371e305edc80597ca1486190252ce493a2ede5cb.jpg)
![](https://media.kbin.social/media/82/6b/826b3c83af8b0f02af606187be950b84b20d40c1306b6ee926d0f9f032c2d537.jpg)
Now to the bits where you completely missed the point.
Photography Gear Verification. *This process is not implemented in Macula, but it was a part of Kelp’s early pilot.
If you’re familiar with how metadata works, you’ll know that your photos inherently contain this information. Your Lens and Camera IDs are included in the Exif metadata and are typically accessible to the public unless you deliberately delete them prior to sharing. If you see this as a red flag, you can go ahead and red-flag any photo management or editing software out there.
To give you an idea, just browse some images on Flickr, click ShowExif
for the selected image, and search for “Serial Number.” You’d be surprised.
Furthermore, if you want to see the full metadata your photos contain, I’d suggest using a metadata checker. Macula has one here: https://macula.link/metadata-viewer/.
Last but not least, you can see how the gear verification is handled by Macula in this demo it’s a bit dated, but still gives you an idea. In our case, only the copyright-related information is shared publicly. The gear ID information is hashed and only used to generate proofs which are included in the ownership statement.
To see and better understand how sharing currently works with Macula I suggest checking this comment
Terms of Service
If you were to give Macula app a try, you’d come across it just before creating your account. It’s that simple, really ¯_(ツ)_/¯
With that, I should point out that the current version we have is a pretty standard setup put together with Termly’s Terms and Conditions Generator. It definitely should be improved once we move forward and can allocate more resources to the matter.
To wrap up, I’d like to say that the projects you see here were mostly brought to life by just two people, with the help of a small team of contractors we assembled around the idea, who were primarily paid from our own pockets, with the occasional boost from grants. If our goal was to exploit the gullible or grab the money and run away before anyone noticed, I assure you we would have taken an easier route. We indeed could have whipped up an empty yet flashy concept, made it appealing to VCs prioritizing profits and quick exits, and by now, perhaps, we’d be signing a deal with one of the industry giants, giving up all we built to strengthen their stance.
Yet, we went fully open-source (which later proved to be not a viable way to lift up), bootstrapping, and investing ourselves over the course of three years to create a robust product with a lot of complexity under the hood. Now, once we have something to show, the point is to gather as much feedback as possible so we can improve the product further.
If you have some more constructive suggestions to follow up, rather than snarky comments earlier, I’m always open to talk.
What somewhat discourages me from responding to the above is not so much your tone of voice, but rather seeing that you’re not paying much attention to what you’re reading.
So, I’ll be brief.
The current ToS indeed fall short, as I mentioned earlier, and they will be changed. I appreciate you highlighting this issue and your frustration about this is entirely justified. The current template doesn’t align with our approach to data handling and is, quite frankly, not up to the mark.
The rest of your comments seem to be rooted in your subjective take on what you generalize as “crypto” and appear to have little to do with the project at hand. You are simply dismissing the facts I clearly laid out in my initial response.
Of course, you have every right to be a snarky asshole, and the internet is filled with such individuals, mostly anonymous, with plenty of time on their hands and, perhaps, a lack of better things to do. So, go ahead and have fun.