Hi, could you explain this section from your TOS?

"You will provide us the right to reproduce, modify or create derivative works from your Content. Obviously we won’t be modifying your Content, we need these rights for example to be able to share your designs with other users. You will also provide us a right to publicly perform or display your Content to allow us to display the material on other users’ monitors.

Base does not claim any ownership on your Content. You hereby grant Base a worldwide, non-exclusive, revocable, royalty-free, fully paid, sublicensable and transferable license to use, host, store, reproduce, modify, create derivative works, publicly perform, display, distribute and transmit your Content."

I am not sure I read it right, but does it say that you are allowed to share my content with whomever you like? And also create new versions of my work?

That's almost a standard disclaimer by now. If this API let's you upload an image and by request (of yourself or a user) it returns a resized version of that image, that might already be a derivative work and distribution of that content.

Thank you for the comment. It's not my intention to claim any ownership of content, I'll review the text and modify it accordingly.

It says that in the quoted text. You still didn't answer the question though.

Looks nice. I’m uncomfortable pushing the password in plaintext to an unknown entity. I can always bcrypt the password locally before sending it through the API, but it would be great to see examples of this, to prevent deva from pushing secrets outside their zone of control.

Otherwise, I can see myself using this in some side-projects. Good work!

When I login/signup to a website, I'm always sending my password in plaintext to the server (obv. encrypted via TLS). What's the difference?

The difference is my customer's don't have a first-party relationship with the data store that holds their password.

    browser -> www.example.com

    browser -> www.example.com -> Base

That's the biggest problem I see with this approach. The password will be seen by two parties instead of just one.

Very cool gdotdesign! We're working on something similar in the decentralized auth space.

Just curious, how/why did you pick email sending as a service add on?

It was easier then implementing it by hand, making sure that they are delivered to the inbox, etc.

who did the design for the website?

It's me, still a one man show :)

Maybe you would need help later. At some point. I can help.