xpressyoo

All the logic happens at the back-end level via our API communicating with Gmail's one. Nothing is done on the client-side (i.e., extension) besides the integration of our buttons/features within Gmail's UI.

The RSA key is just used to show that what has been inserted was through our service. Note that the final hash resulting from the mixer is done without any RSA.

EDIT: reply to your last comment. The whole idea is to propose a "hybrid" architecture that bridges the gap between a centralized technology such as the Email with the benefits of a decentralized one, the blockchain.

This hybrid process implies you will need to trust parties at some points, e.g., Google and Gmelius. However, the point here is to offer a means to store in a robust way the trace that a specific email communication existed at a point in time, including its context/content.

Yes, we integrate with Gmail and communicate via the official Gmail API.

We only receive response statuses and act accordingly. Moreover, we think it's important for this functionality to make sense to insert the hash corresponding to the integrity of the email, and so make possible for our customers to "prove" they have indeed sent an email with a specific body/subject/...

Thanks for your comments.

"They both supply email tracking, and protect your privacy by blocking email tracking."

This is mainly offered to prevent false positives for our own trackers. But point taken :)

"It doesn't prove that the email has been sent, it just proves that it has been submitted to Gmelius for signing."

The insertion is done when we have received a response from Google servers.

"SHA-512"

Long debate but this was the most natural solution for a Merkle architecture.

The insertion is only done once we have received a response from Google servers that the email has been indeed sent (without bounce or other errors).

Hi vivan. Thanks for your comment. Besides the signature of an email using the robustness and persistence of the blockchain, what is different with "Email Stamping" and especially interesting for professionals who send sensitive emails (e.g., lawyers, insurers, brokers...) is that they have a way to show they sent an email with a specific content at a specific time.

A decisive challenge raised by today’s email dominance in the workplace is that the latter means of communication does not offer a built-in function to prove the integrity and authenticity neither of its content nor of its origin. Knowing that emails are increasingly presented as legal evidence in courts worldwide, it becomes urgent to think of approaches that could palliate the inherent flaws of email.

EDIT: And yes, Gmelius offers a lightweight CRM targeting SMEs that covers all the stages of the modern communication flow: from the first interaction to the potential signature of a contract/quote. Besides, Gmelius offers a shared inbox making possible to follow-up on leads, stay in sync with your team.

Gmelius (https://gmelius.com) detects and blocks pixel trackers in Inbox.

Gmelius (https://gmelius.com) detects and blocks pixel trackers within Gmail and Inbox. We'll soon release a way to prevent link tracking. You can learn more about this privacy feature at https://gmelius.com/gmail-block-trackers/

This is on our roadmap and will be added to Gmelius for Inbox soon.

Hi! Regarding your tracking remark, companies such as YesWare, MailTrack, MixMax (and so on) use pixel trackers. While such trackers are indeed made available through a Google proxy, the caching is overridable if you pass a no-cache header (http://blog.movableink.com/real-time-content-and-re-open-tra...). The Inbox SDK makes easier the interaction with Gmail's UI and does not transmit or index data.

You can do that with Gmelius (premium tier) by enabling the so-called feature "Edit the subject line in reply and forward".

Thanks for your comment. When a user enables the feature that homogenizes the look of incoming emails w.r.t. its Gmail theme, Gmelius will not modify the style of well-formatted HTML emails (e.g., invoices, newsletters, etc.).

Weird. Feel free to contact support. Do you use any other Gmail extensions? If so, which ones?

In addition to our "email scheduling" feature, email follow-ups and reminders will be soon available as well. With the latter features and other ones Gmelius currently offers (e.g., To-do App, email trackers detection and blocking, email templates), I'm sure your will find a place for Gmelius in your browser...

Feel free to take a look at our Privacy Policy: https://gmelius.com/privacy

If you need more convincing, just go through our code after installing the extension and/or check your console and network when using Gmail with Gmelius installed.

Thanks! Fixed.

Great job and initiative! Gmelius Founder here. A few questions:

i) Are you planning to make the whole implementation Open Source?

ii) Say I wish to adopt and use your SDK in my current Gmail/Inbox extensions (>100K daily users), may I expect the implementation of a fixed upper limit on the number of transmissions in the coming months (which could endanger the reliability of my service for my users)?

iii) While the SDK currently only focuses on the UI, are you planning to add more "complex" interactions, such as Gmail filters/Gmail preferences ? If yes, feel free to get in touch. I will be happy to help.

Congrats, again.

This is a Beta release. Your suggestions and feedback are more than welcome. Thanks in advance.

-- Florian, Gmelius dev

Feedback and suggestions very welcome.

This is an early (beta) version of Gmelius for Google Inbox, currently available as a Chrome extension. Feel free to share your suggestions and feedback. Thanks in advance!

This link, I presume: http://silverman.svbtle.com/the-best-time-to-post-on-hacker-...

I completely agree. It would be great to add a subsection to Hacker News dedicated to this kind of stories, e.g., "discover" or "showHN".

Hi Costin,

Yes, I'm currently working on a way to differentiate emails per day. I tried to colourize the rows to achieve that but was not convinced. The current approach rests on borders of different colours. This should be out as a free Beta feature in the coming weeks. Best.

Yes, my bad. Last submit. Thanks.

Hi,

1. To be brief, there is no server-side code, so all your data stays in your browser. For more info, please see: http://gmelius.com/privacy/

2. No, Gmelius should not slow down Chrome.

Any suggestions/remarks about the website and/or the features are welcome and encouraged. Thanks!

Hi Kartik, Gmelius (http://gmelius.com) developer here! Great stuff. Will be glad to help you maintain the API up-to-date, if you wish so :)

@KillSwitch, "active" ad-avoiders use ad-blockers and "passive" ad-avoiders ignore them, leading to the same output, i.e. no revenue (CPC, 2/3 of all online advertising compensation methods, and growing). Now let's take the case of Gmail, Gmelius gives the possibility to its users to hide ads but does NOT block the parsing of messages by Google and so the gathering of information used by Adsense to propose "customized ads" on other domains. Now, you don't seem to take into account the fact that this overflow of ads we have to face (more and more) on a daily basis actually encourages people to become active or passive ad-avoiders, decreasing then the income generated by ads. I clearly think this kind of business model is not viable over the long-run...

@KillSwitch, "active" ad-avoiders use ad-blockers and "passive" ad-avoiders ignore them, leading to the same output, i.e. no revenue (CPC, 2/3 of all online advertising compensation methods, and growing). Now let's take the case of Gmail, Gmelius gives the possibility to its users to hide ads but does NOT block the parsing of messages by Google and so the gathering of information used by Adsense to propose "customized ads" on other domains.

Now, you don't seem to take into account the fact that this overflow of ads we have to face (more and more) on a daily basis actually encourages people to become active or passive ad-avoiders, decreasing then the income generated by ads. I clearly think this kind of business model is not viable over the long-run...

Not sure ad-avoiders should be always seen as content-killers. I think this is a bit more complex than that. A good read: http://www.newyorker.com/online/blogs/elements/2013/10/is-ad...