ChastiKey Forums

General Category => ChastiKey Chat => Topic started by: KevinCross on November 06, 2018, 10:44:13 PM

Title: ChastiKey API
Post by: KevinCross on November 06, 2018, 10:44:13 PM
Hi

I've amended the API to use user id on the URLs instead of the token meaning anyone can easily work with this without requiring a token from me. I'm hoping with the more people that play around with it the more feedback and suggestions I'd get to help improve it.

I've produced a page of documentation here https://www.chastikey.com/api

I've left the v0.1 and v0.2 folder and files as they are incase anyone is using them, but going forwards please disregard the last forum post discussing the ChastiKey API.

Let me know what you think.
Title: Re: ChastiKey API v0.2
Post by: Tawny on December 27, 2018, 08:28:40 PM
Link seems to be broken
Title: Re: ChastiKey API v0.2
Post by: KevinCross on December 28, 2018, 08:10:25 AM
Link seems to be broken
Sorry must have changed the link when moving to the new server. The link works now
Title: Re: ChastiKey API v0.2
Post by: sweh on January 25, 2019, 02:27:37 AM
Suggestion: For the check call, if the result is unlocked then also return the combination lock.

The use case I'm thinking of is a semi-smart lock that has a simple command interface ("lock 12345", "unlock 12345").  The user could create a session as normal, enter the combo into the smart lock and then have external code (eg running on the PC) which periodically checks the lock status.  If the session is unlocked the code can then send the combo to the smart-lock ("unlock 12345") and have it unlock.   Obviously all user interaction (card draws, etc) would be via the mobile app.

Splitting the logic between the semi-smart lock and external code has a number of advantages from a build perspective; no networking needed for the lock, itself.  But it means the combination must be known to unlock; you can't just send a "session complete" message.

Such a system might also be usable for self-unlocking self-bondage locks, or door locks ("locked in a room until Zoe lets you free") where the lock and controls are unreachable; you just have your mobile app to play the game and hope you'll be released :-)
Title: Re: ChastiKey API v0.2
Post by: KevinCross on January 25, 2019, 09:10:28 AM
Sounds good @sweh. I can add it to show when unlocked. I can't see a problem with that.
Title: Re: ChastiKey API v0.2
Post by: KevinCross on January 27, 2019, 10:41:09 AM
@sweh the combination is now available in the API data. I've also included the combination for the fake locks. If the lock is still locked the combination will return 0

The API page has been updated: https://chastikey.com/api
Title: Re: ChastiKey API v0.2
Post by: sweh on January 27, 2019, 12:07:30 PM
Nice :-)
Title: Re: ChastiKey API v0.2
Post by: sweh on January 27, 2019, 12:58:27 PM
I'm trying to think of other things you can expose which won't drive people away from the app-first nature of this  (I'm assuming you get non-zero revenue from advertising and I don't want to reduce that).

Two possible thoughts

  1.  Add "Frozen" to locks.status option
  2.  Add "time remaining until next card draw" to locks  ("-1" if frozen).

This would allow for silly things like if someone has a Hue light bulb system then the lights could turn blue if the lock was frozen, and the lights could flash if the lock is ready to be tried again.

These shouldn't take eyeballs away from the app; already my smart watch buzzes when the "one of your locks is ready" android notifications appears.

If you're not too worried about app eyeballs (but still require the app, for session creation and for emergency key purchases) then extend the lock structure to include card counts (unless hidden).  Someone could write an Alexa skill "Alexa ask chastikey for status"... "you have been locked for 7 days 3 hours by Zoe.  There are 7 red, 1 green, 2 freeze, 4 double cards remaining.  You can try next in 3 hours".

Once we go down this path, adding a new endpoint to perform the interaction "select card <n>"  ("Alexa tell chastikey to turn card 27"; "you picked red".  "Alexa add 3 reds"; "OK there are now 16 cards on the table") but this might be going too far away from the app-first design.

Ideas?  I have them :-)
Title: Re: ChastiKey API v0.2
Post by: KevinCross on January 27, 2019, 02:56:23 PM
I think those are good ideas. I specifically like the Alexa one. I'm not too fussed missing out on a few pennies because a couple of users use the API to get the data without ever going in to the app until it's time for them to pick. The ad revenue is quite small.

I will have a look at adding more data soon, like the data you've suggested
Title: Re: ChastiKey API v0.2
Post by: sweh on January 27, 2019, 08:53:31 PM
Question: Should `combination` be a string?  I just created some test locks of type ABC and the results are wrong;

{"lockID":1548621080,"lockedBy":"Zoe","timestampLocked":1548621080,"timestampUnlocked":1548622082,"status":"UnlockedFake","combination":0},{"lockID":1548621080,"lockedBy":"Zoe","timestampLocked":1548621080,"timestampUnlocked":1548622102,"status":"UnlockedReal","combination":3},{"lockID":1548621080,"lockedBy":"Zoe","timestampLocked":1548621080,"timestampUnlocked":1548622112,"status":"UnlockedFake","combination":8}

The combinations are U44UD6B3, 3STFTKE6, 8LWU7QBH so it looks like the value returned by the API is the leading digits(if any).  (U...->0; 3S...->3; 8L...->8 ).

EDIT: It should probably be a string even for numeric combinations 'cos leading zeros need to be preserved.
Title: Re: ChastiKey API v0.2
Post by: sweh on January 27, 2019, 11:33:33 PM
Something silly that only took a few minutes to put together...

https://bdsm.spuddy.org/test/chastikey.mp3 (https://bdsm.spuddy.org/test/chastikey.mp3)

(That's a real session, but I faked the holder's name in my code to prevent her name from leaking; she doesn't use this site).
Title: Re: ChastiKey API v0.2
Post by: KevinCross on January 28, 2019, 07:42:27 AM
You're right. It should be a string. I've fixed that now.

I like the Alexa skill! Are you working on one or was it just a scripted message to show what it might sound like if someone did create it. If you are, let me know if you want accese to more stuff in the api or seperate versions set up for it.
Title: Re: ChastiKey API v0.2
Post by: KevinCross on January 28, 2019, 07:49:23 AM
I've been producing json data files for the developer of the Discord bot so that users can access their stats and other lock information amd have the bot show it in Discord. I'm more than happy to create more API scripts so that an Alexa Skill can access more informatiom than the current API shows. Pretty much anything in chastikey.com/stats can be accessed plus more. The Discord bot accesses the total locked time from all locks too so you could ask "Alexa, what's my total time locked with ChastiKey" to which she could reply "You have been locked for a total of 10.2 months across 43 locks"
Title: Re: ChastiKey API v0.2
Post by: sweh on January 28, 2019, 11:49:40 AM
The Alexa response was a real call to the API to fetch the data :-)

So far it just calls listslocks.php and then parses the JSON.  It's written in GoLang and just converts the Lock array into a string

e.g.

func parse_api(json_str string) string {
        var chastikey Chastikey
        err := json.Unmarshal([]byte(json_str), &chastikey)
        if err != nil {
                return "Could not understand API results: "+err.Error()
        }

        // We want to look at the chastity session
        s := chastikey.Locks

        cnt := len(s)
        res := "You have " + strconv.Itoa(cnt) + " lock"
        if cnt != 1 {
                res += "s"
        }
        res += ".  "
        for x,y := range s {
                dur := time.Now().Unix()-y.StartTime
                res += "Lock " + strconv.Itoa(x+1) + " is held by " + y.LockedBy + ", and has been running for " + time_to_days(int(dur)) + ".  "
        }

        return res
}


It's not good code, but it works!

Unfortunately I don't think this sort of skill can be published on the Amazon store so it has to be run development mode, which requires users to have some knowledge on how to set up a TLS web server, but I'll publish the code and instructions on configuration.

Whatever you decide to expose, I can add a routine for ;-)
Title: Re: ChastiKey API v0.2
Post by: jglasman on February 11, 2019, 02:01:13 AM
Great to see an API.  I was playing with it to see if I could use it for some of my remote controlled stuff
   Documentation page http://www.chastikey.com/api/doku.php has a typo on the tense of the API.  it has checklocks.php (plural) and the actual API is singular.
 
   Also it would be nice to mention that userid must be in all caps (or perhaps update the API to uppercase before doing the lookup?

   Finally the API does not show when a lock can be opened but still locked. That is nice for remote control to automatically unlock a lock--say a magnetic lock holding keys or .....

Once again great job and great to see an actively developed application!
Title: Re: ChastiKey API v0.2
Post by: KevinCross on February 11, 2019, 10:02:35 AM
Thank you for mentioning the typo. I'll try and correct that today. I'm surprised the user id is case sensitive as I don't thibk the database table is but I'll have a look and will update the documentation accordingly.

Are you saying you want the API to show when the lock is due to finish? That is doable but only applicable for fixed locks where the timer isn't hidden. Would you not run into issues or wouldn't it be flawed it relied on this timestamp only, especially if the keyholders hides the timer during the lock, so when created it was due to end in 4 days, after 2 days the keyholder hides the time and adds 10 days. If your lockbox relies on that timestamp wouldn't it unlock after 4 days, even though 10 days was added just because the time to unlock timestamp is hidden in the API data
Title: Re: ChastiKey API v0.2
Post by: jglasman on February 11, 2019, 04:17:08 PM
Thanks for the reply.

I would like to know that the status of the key is ready to be unlocked. Not the actual time length.  Though knowing the time length might be nice as well for timed locks.

My thoughts is add a few status
so you have UnlockedFake, UnlockedReal, sucess  already.  My thoughts would be add something like "KeyAvailable" when the timer or keyholder has unlocked it but the lockee has not yet tried the key.  (LockedReady or LockedKeyAvailable ... any words to that effect would work just as well)
You can't see at this point if if a real or fake key since the user does not know.  If the keyholder adds time before the lock is tried it would update back to the Locked status.

Any remote app would just send a once every minute or so query to your server so it does not need to predict when it will be unlocked. If it notices the status that the key is available it could then remotely unlock its lock. If the key turns out to be fake the lockee might still not be able to enter a lock box but that is not the fault of the api.

If you want to populate the time in the future for timestampUnlocked of when it would be unlocked but not update the status that would be OK for timed locks but that isn't what I was after.  That would be nice in that a remote API could use that data to update a color light or something though perhaps that is better handled by a different field that would also give a prediction of the number of cards in the case of non-timed lock but that is a different request.
Title: Re: ChastiKey API
Post by: KevinCross on February 11, 2019, 11:25:14 PM
There's now a version 0.3 of the API available. I've created a new version because of a new status code addition: ReadyToUnlock

I've also added a flag to show if the lock is frozen or not

https://www.chastikey.com/api/doku.php?id=v0.3

Please let me know if you find any problems or want other things added to it.
Title: Re: ChastiKey API
Post by: jglasman on February 12, 2019, 12:38:07 AM
very good. I'll give it a go and let you know if I see an issue. You were rather quick about it!
Documentation page doesn't show the new status
Title: Re: ChastiKey API
Post by: sweh on February 12, 2019, 12:52:07 AM
Hmm, https://api.chastikey.com/v0.3/listlocks.php?userID=my-user-id-tag gives a 500 Server error.  The v0.2 entry still works.

EDIT: It appears as if the v0.2 entry has been updated so it includes the "frozen" attribute.

Also the documentation is still listing combination as a number, when it's really a string.
Title: Re: ChastiKey API
Post by: jglasman on February 12, 2019, 07:10:10 AM
with 0.3 the listlocks tosses a 500 error regardless of input.
The checklock for a variable lock is not showing readyUnlock

thanks again
Title: Re: ChastiKey API
Post by: KevinCross on February 12, 2019, 08:40:38 AM
The 0.3 not loading issue has now been fixed. I'll have to have another look at the ReadyToUnlock flag. It looks like the app isn't always updating the database correctly when it's on your device ready to unlock.

And yes frozen was added to 0.2 as it was an extra variable so unlikely to break things for people already using it. Adding the new ReadyToUnlock flag in an existing variable might have caused issues so created a new version.

I've fixed the documentation so that combination shows as strings. Thanks.
Title: Re: ChastiKey API
Post by: KevinCross on February 12, 2019, 08:46:32 AM
Here's another users lock with the ReadyToUnlock flag showing

Code: [Select]


{"response":[{"status":200,"message":"Success","timestampGenerated":1549961097}],"locks":[{"lockID":XXXX,"lockedBy":"XXXX","lockFrozen":0,"timestampLocked":1525568430,"timestampUnlocked":0,"status":"ReadyToUnlock","combination":""}]}



It works, just not all of the time, but that's an app issue that would need to be looked into and fixed.
Title: Re: ChastiKey API
Post by: sweh on February 12, 2019, 11:50:55 AM
I've fixed the documentation so that combination shows as strings. Thanks.
Almost :-)  The JSON now looks right, but the description still has "Will return 0 if not yet unlocked" in both places.
Title: Re: ChastiKey API
Post by: KevinCross on February 12, 2019, 08:21:20 PM
Thank you @sweh I've fixed that error now in both versions.
Title: Re: ChastiKey API
Post by: jglasman on February 13, 2019, 05:25:05 PM
It appears that that the readyToUnlock only shows up after the application has run in the forground and has a chance to evaluate the lock.  That makes sense now that you mention it as the logic is in the app and not on the server.  It does change some things as it makes it not possible to do remote unlocking without touching the phone (at least in Android) as the app will be sleeping.
Title: Re: ChastiKey API
Post by: CHT on April 13, 2019, 12:40:05 AM
Sorry if this is a double-post but I think the previous one was eaten...

Anyway, just found this app, and am having fun with it.  Well written and nicely done...

I have an esp32-based lockbox that I've made, which currently is just time based, that I'm adapting to use with this api.  Once the username and lockid have been entered on the esp32's web interface, the esp32 can go pull the lock status from the api, and unlock once 'UnlockedReal' is seen for the lockid.  That part is good.

The part that is not so good is that I haven't figured out a way to make using it easy.  Each time it's locked, I need to get the shared lock, start it, and then enter the new lockid into the lockbox web page. 

It would be nice if a shared lock could be made 'persistent', so that the same lockid could be reset either by the hw or the user, as if it was being re-loaded, but keeping the same lockid.   

If I can get it working a little smoother, I'd be happy to share the construction, esp32 code, etc.
Title: Re: ChastiKey API
Post by: KevinCross on April 13, 2019, 08:29:19 AM
At the moment you can't restart a lock once it has unlocked, but that will likely change in a future version

I don't think a lockbox should be stuck to work with the one lock though because that means you can't create new and longer ones when you're trying to set personal goals/records
Title: Re: ChastiKey API
Post by: CHT on April 13, 2019, 04:14:57 PM
I don't think a lockbox should be stuck to work with the one lock though because that means you can't create new and longer ones when you're trying to set personal goals/records

I agree here... When the box is unlocked it's possible to choose any keys.  I haven't used chastikey that much yet, but based on the previous incarnation of the box which uses time, my wife almost always uses the same settings to start, and then adjusts it once its running. 

Making it really quick and easy to re-run a shared session is really the goal.  Maybe even just save a list of previously loaded shared locks?  I could just have the box find the first locked key managed by a specific user...

BTW, The discussion with my kh is that one mode she'd like to have a variable lock available that starts frozen.  She could then unfreeze as she saw fit to give me chances...
Title: Re: ChastiKey API
Post by: jglasman on April 16, 2019, 01:07:23 PM
CHT:  You could use just the user ID and not the individual lock.  So if any lock is running for that user it stays lock?
Title: Re: ChastiKey API
Post by: zorkl on May 17, 2019, 11:01:48 PM
There's now a version 0.3 of the API available.

Hi Kevin, I just wanted to say thank you for the API. This is great.
I discovered that the API URL can also be accessed through unencrypted HTTP http://api.chastikey.com (http://api.chastikey.com).

This may weaken security as the server messages can be intercepted.
Unencrypted HTTP may be acceptable as long as no commands can be issued through an API call.

But: Please don't close this loop hole! I am using the API to control a rather complicated smart lock: a cell door lock operated by a micro controller. I built it almost a decade ago. It is still in use and its function has greatly improved through Chastikey. Because there is no newer driver for the microcontroller available, all physical lock control software has to run on Windows XP. Windows XP doesn't support TLS 1.2, which is used at the HTTPS site. Therefore I can only connect to the API through unencrypted HTTP. Shutting downs the HTTP port would cause a small problem here.

Love,
zorkl

Title: Re: ChastiKey API
Post by: CHT on May 21, 2019, 08:59:26 PM
Interesting (?) bug... I have a lock that on the app has unlocked, but in the API still shows as locked?  Lock 1558398531 is the incorrect one... the other lock is still active....

(It's not important, as I've already unlocked it, but if I was using this lock for my lockbox I'd probably be a little less happy! :)

http://api.chastikey.com/v0.3/listlocks.php?username=CharlieH

The JSON response is:

{"response":[{"status":200,"message":"Success","timestampGenerated":1558468145}],"locks":[{"lockID":1558398531,"lockedBy":"Hailey","lockFrozen":0,"timestampLocked":1558398531,"timestampUnlocked":0,"status":"Locked","combination":""},{"lockID":1558447634,"lockedBy":"Hailey","lockFrozen":0,"timestampLocked":1558447634,"timestampUnlocked":0,"status":"Locked","combination":""}]}

http://api.chastikey.com/v0.3/checklock.php?username=CharlieH&lockid=1558398531

{"response":[{"status":200,"message":"Success","timestampGenerated":1558468559}],"locks":[{"lockID":1558398531,"lockedBy":"Hailey","lockFrozen":0,"timestampLocked":1558398531,"timestampUnlocked":0,"status":"Locked","combination":""}]}

Title: Re: ChastiKey API
Post by: CHT on December 29, 2019, 06:11:31 PM
Don't know whether you're still monitoring this thread, but a problem/request...

Using the API w/ my esp32-controlled lockbox, I look for a lock ID that is set when the box is closed.  No problem there.  I run into a problem, though, if the lock is deleted... the only reasonable option is to open the lockbox.  So, I can 'get out' simply by deleting the lock...

A couple of possible solutions...
1) Running locks can't be deleted (I think this is a suggestion on the 'regular' app as well.  I'd prefer this one...)

2) If the lock is held by a keyholder, allow the API to enumerate locks held by keyholders, and if a user deletes a lock have it still show up (and be maneagable) by the keyholder, even if deleted by the user.  I think this is messier... I don't really like this option.

Title: Re: ChastiKey API
Post by: KevinCross on December 29, 2019, 07:05:19 PM
The next version of the app gives you an option to disable deletion of locks that are running.
Title: Re: ChastiKey API
Post by: CHT on December 30, 2019, 02:02:31 AM
The next version of the app gives you an option to disable deletion of locks that are running.

Who has the control of disabling lock deletion, though?  The lockee, or the key holder?  If the lockee can control the enable/disable of lock deletion, then I (lockee) could still just enable lock deletion and delete the lock, right?
Title: Re: ChastiKey API
Post by: KevinCross on December 30, 2019, 10:37:07 AM
Yes you could. It isn't added to stop you from doing that, its to stop you from accidentally deleting it. If you enable it and then delete the lock then it's not really an accidental deletion. It shouldn't be up to a keyholder as to whether or not you can delete a lock you no longer want.
Title: Re: ChastiKey API
Post by: guest1224 on December 30, 2019, 03:23:30 PM
Don't know whether you're still monitoring this thread, but a problem/request...

Using the API w/ my esp32-controlled lockbox, I look for a lock ID that is set when the box is closed.  No problem there.  I run into a problem, though, if the lock is deleted... the only reasonable option is to open the lockbox.  So, I can 'get out' simply by deleting the lock...

A couple of possible solutions...
1) Running locks can't be deleted (I think this is a suggestion on the 'regular' app as well.  I'd prefer this one...)

2) If the lock is held by a keyholder, allow the API to enumerate locks held by keyholders, and if a user deletes a lock have it still show up (and be maneagable) by the keyholder, even if deleted by the user.  I think this is messier... I don't really like this option.

I'm looking to create a lockbox with esp32 as well. Would you mind sharing more detail? The code I have was from an old emlalock box idea I found years ago that I dont use anymore.
Title: Re: ChastiKey API
Post by: Tawny on January 06, 2020, 03:11:40 AM
I am using an ESP8266 with the API to control a lock box if you want more info DM me on discord
Title: Re: ChastiKey API
Post by: cuffed on January 10, 2020, 10:56:26 PM
When I lock my device I enter the code in to it. When I trigger the release all the codes given by the API are checked and the lock released if any match. If the lock is deleted the code is lost.

Another option could be to store the lock ID when the device s locked so only that lack can release it.