As I’m migrating from EverNote to Bear, I do find EN features I miss when using Bear.
In Evernote one can create an e-mail address within the app and send e-mail to <whatever_name_95871tr87qtq@evernote.com. That e-mail is added as an article/note. You can even add tags and notebooks in the header. Quite nifty and handy.
This seems extremely unlikely as Bear is using iCloud for sync and the devs are not controlling that. You may want to take a look at Shortcuts instead to send content to Bear.
Surely this is still possible even if you don’t have direct access to the user’s data.
What if xxx@notes.bear.app held the email in some kind of API inbox for the user’s Bear App to pick up and transfer to iCloud when it next opens.
SMTP handles the failure case quite well too. If a message never reaches iCloud, you can respond to email with an “Undeliverable Email” response. Maybe you have a time limit of 30 days for a user to open Bear App or something.
I have played a bit with CloudKit and let me tell you, this is not trivial. Replicating any kind of cron job as you suggest is hairy with iCloud and a server you don’t have the keys of. iCloud is designed for storage and data, not remote execution of code. (There might be ways to do it but it’s far from a simple thing as with other solutions. Google’s work better for this.)
That is what I understand about it too. And my point is is to get the client application on the user’s device to do that work. So the final leg of the mail delivery happens when the user opens Bear on their computer.
Infact all the technology exists to do this in the world of POP3. You could pretty much implement a notes.bear.app with an off the shelf mail server.
It is somewhat hilarious to think that Bear App could have a POP3 client in it. Dial up internet anyone?
(I can’t remember the state of SSL on POP3 etc. Wrapping that in a HTTP API likely to be a good decision)
This means we have to identify the user on our hypothetical pop3 server and add some kind of profilation to Bear.
Right now the oses ensure you are you based on the iCloud account in the preferences but nothing about it is shared with third-party developers. A profilation, meaning users have to verify their iCloud accounts in Bear, allow us to associate an email.
Regardless of the inevitable complications of adding a second server to the sync, the above concerns me more on a privacy perspective because you can do very bad stuff with someone’s iCloud credentials.
But one shouldn’t open a can of worms only for a bit of functionality
It’s fun to think of it. But more then that I want bear to be more successful - there are going to be a lot of Evernote users who are blocked from migrating because their current process requires something like this.
There is an iCloud decoupled solution that exists, proof of that is that you can solve this now by creating an Apple shortcut in the Automations tab that gets triggered on “Email”. It is clunky though, and some users may not have the right email system setup that could make that workable.
@trix180 I have more thoughts on the matter, but probably too technical for the scope of the forum if you want to reach out to me.
I migrated from Evernote to Bear and I don’t miss too much. It became bloated and expensive as well (price tripled in 10 years).
I love the simplicity of Evernote and the way it’s structured. The UI is great.
However, I do miss mailing stuff.
Now I can’t use it any longer, I became aware how often I used it.
Even more as I need to use a Windows laptop at work and I can’t anything to Bear directly. Having the possibility to e-mail stuff, would be a splendid option.
I’m unsure about what you mean here, but if the idea is using Shortcuts to sync the mail notes, it’s indeed quite clunky and I think the main issue remains the profilation because server-side we have known xxx@bear.app is yours.
I think we can go a little technical here. Please tell me more.
So, the Apple Shortcuts solution shows that an on device process can pick up emails and create notes, without direct access to the Bear iCloud data store. For the sake of demonstration you could consider a feature in bear that replicates this where:
Bear had an IMAP/POP3 incomings settings tab in Bear
On regular intervals, in Bear, Bear would poll the email server configured in the settings for new messages, create notes and delete messages from that server.
In that scenario:
The mapping between the transport configuration (the email settings tab) and the storage solution (iCloud etc.) is in Bear on the device. That is what I mean by a de-coupled solution. You only need to store the settings values themselves, perhaps in iCloud or other secure location. Or in the Bear database itself. User-end profilation i suppose.
This requires the Bear app to be open in order to ingest email. I don’t believe this is a problem because (correct me if I’m wrong) the Bear App is the only interface that talks to its data – there is no other system that is depending on notes being created from email when Bear is closed. Maybe Apple Shortcuts?? Even still I think it is a process with the same behavior set as the current Bear iCloud Sync.
My point is, putting this process in Bear makes it transport problem not an iCloud access problem.
Going a step further because IMAP/POP3 settings inside of bear would be terrible. Everything involved in the creation of an email account, its authentication and population of settings needs to be wrapped up in a button “Copy incoming email address”, or something of that effect.
The most strait forward way to create an email address is for Bear to hit an endpoint asking for one. The endpoint only needs to know that a request came from a valid install of Bear – it doesn’t need to know anything else. That appears to be something Apple has a solution for (Validating apps that connect to your server | Apple Developer Documentation) I’m not an app developer so I don’t know much more about how to implement that.
One final point. Because what I’m proposing is that the email ingestion and processing happens in Bear, there is actually no requirement that the user is using iCloud sync at all. They could indeed be on the free tier, which is the same as Evernote. It is worth to consider.
It would really be great if “we” (…) could make this work.
Not only for me of course. It would make lives easier for many Evernote users. And, next to that, it’ll be an advantage for all other users as well. We’re not bloating Bear, but we do add easy-to-use functionality. If possible, that says.
Drafts has this feature indeed. I tested it after reading your response and it works well.
At the moment, I’m sending e-mails to drafts, and from Drafs I say, send to Bear.
A bit odd, but it works.
As Drafts doesn’t support attachments (except text), it isn’t perfect either. The markdown hashtag header isn’t processed, but turns op as a hashtag in Bear.
So, the workaround is, a workaround. And I have to pay 2 subscriptions…
But for the time being, I’m good.
It’d be better if it’s solved within Bear. I like the app better in general.
Started using Zapier (first time user) and created the Zap
At the moment all new e-mails are processed, need to add a filter (fingering this out atm)
Anyhow, all new e-mails are processed, and dropped into a Dropbox folder, timestamped and containing the exact content and formatting I prefer
Check!
However…
Getting the MacOS Automater running is a hassle, shouldn’t be hard
Your final step “Apple Shortcut importing…” feels like a manual step. Or am I mistaken?
If so, the offered flow (many thanks for that) is a workaround, but not a solution.
Both Evernote and Drafts can do the trick themselves already.
Yeah,
I know ENs Architecture is different. And I don’t like it/them/pricing any longer.
I’m using Drafts (and paying a monthly fee) just to receive and process my e-mail. Within Drafts I can send to Bear (a pre-defined albeit manual step).
So, this shortcut is triggered by the automator workflow above, but can also be run manually (unfortunately, not able to get this to work with Dropbox on iPhone/iPad, not even manually)
I filter on email subject, because I use an old Gmail account that receives other mail and to avoid possible spam. Otherwise filter/Search may not be necessary: