Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't create promises (for new username?) #313

Open
artemiswkearney opened this issue Oct 8, 2019 · 4 comments
Open

Can't create promises (for new username?) #313

artemiswkearney opened this issue Oct 8, 2019 · 4 comments

Comments

@artemiswkearney
Copy link

artemiswkearney commented Oct 8, 2019

I've tried to load http://arti.commits.to/test_promise from many browsers, both desktop and mobile. The "Creating your promise..." progress bar consistently stops at 80%.

@artemiswkearney
Copy link
Author

Update: does seem to be related to the user being new! Manually POSTing commits.to/api/v1/user/create with body { "username":"arti" } made promise creation via arti.commits.to work.

@dreeves
Copy link
Contributor

dreeves commented Oct 14, 2019

Hi Arti! Nice work figuring this out and filing a gissue! That alone probably means you can go to the front of the list for a beta account, but we are still manually approving those! So let's chat by email and I can give you the spiel. (Roughly, having a beta account and reserving a username means committing (!) to help with development of commits.to!)

@ghost
Copy link

ghost commented Apr 3, 2021

I think that this account creation policy/process/etc should be documented on the main README of this repo and/or on the webiste home page.

also, is there authentication to make sure that someone does not create commitments on another user's account?

@kingdonb
Copy link
Collaborator

There is no authentication at all. And it has occasionally been a problem, but not one that we can solve easily without making compromises. It might be time to add authentication.

The understanding I got from reading the spec (a long time ago) was that you should be able to fire-and-forget promises in an e-mail, and when the person you promised it to "clicks through" then it triggers the javascript person-detector and lets the promise be created, on GET. So if that person is never interested enough in the thing you said you'd do to check if you did it, you are never placed "on the hook" for making that promise and it doesn't count against you.

It's not part of the spec that others should be able to spam promises into your queue without your permission. I'm not sure how to reconcile those goals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants