A few proposals

[santomet]

Hey! It is a very nice project, I wanted to do something similar myself (but have none experience with flipper development yet). I would like to discuss a few points before this gets big :)

• Instead of a format link (or together with that) I propose a reference to Silca card number. This can also be shown on the screen during measurement. Silca because it has the biggest worldwide database and can easily be found in InstaCode.
• A file format for a key "system" instead of data compiled in binary. Why? Since this has the potential to get huge, we need a way to parse the information effectively. I suggest having a directory per manufacturer and a file per system.
• Together with the above I propose a two-level menu, first, you select the manufacturer, then a particular system.
• For the file format think upfront about double-sided keys
• Show where a stop is (and think about the possibility that some systems have a tip stop)
• Maybe use 1/100 mm instead of inches as that is a standard outside the US? All US systems can also be defined with mm/100.
• With that a universal mode where the user can move pixel-by-pixel and save positions. Instead of bitting a 1/100 mm values for depth and spacing would be saved/shown

What do you think? I know that is a hell lot of work but worth it. If you agree to at least part of this, I would be motivated to work with you and learn the basics of Flipper development :D

Take care
(Btw I removed this from issues as I have noticed discussions :))

[zinongli]

Thank you for your interest in this project! I'm more than happy to have more people collaborating here. I'm vey new to Flipper Zero development too and this is the first app I've made. So I'm still learning. I'm not familiar with locksmith and key making at all. I started this project hoping that it gets enough attention that I can get help with experts in this field.

• Instead of a format link (or together with that) I propose a reference to Silca card number. This can also be shown on the screen during measurement. Silca because it has the biggest worldwide database and can easily be found in InstaCode.

Totally. I'm very interested in linking the key formats to an open and public database, something like a wikipedia for keys. I attached those file from Locksmith Security Association of Michigan only because I found their data very thorough when I was developing this app. Currently I encoded those data in this format which I'm sure you have read. What do you think would be a better way to encode them? I'm using very amateur naming for the data and I'm sure there are more types of information about each format that should be in there. I checked out the Silca number you mentioned. Were you referring to their 110 catalog? It is a massive database but I couldn't find more specific info for each key. And I don't think I have an InstaCode account to use their app.

• A file format for a key "system" instead of data compiled in binary. Why? Since this has the potential to get huge, we need a way to parse the information effectively. I suggest having a directory per manufacturer and a file per system.

I'm not sure if I understand what you mean by "system". For example, if I'm dealing with Kwikset KW1, is "KW1" the system? Again, I'm very new to this field so I apologize for not knowing the terms. If my understanding if correct, then what you are proposing is a great idea. It would take some extra work, but definitely doable. Although, I think we should first decide on how we encode the formats/systems in the source code before deciding on the user interface.

• Together with the above I propose a two-level menu, first, you select the manufacturer, then a particular system.

I'm not very inclined to the idea of making the users do one more click every time they load a key. It's they freedom to create folders themselves, but I don't want to make it mandatory. Same applies to NFC and LFRFID apps, they don't store cards according to protocols.

• For the file format think upfront about double-sided keys

Double sided keys is the same as select-by-manufacturers. Doable, needs some work, and should come after we decide on the format/system encoding in the source code.

• Show where a stop is (and think about the possibility that some systems have a tip stop)

I'm not sure if I understand what a stop or a tips stop is. Is it this position in the red circle?

If yes, I have bad news: I don't know where to find that data. :( But any help is appreciated.

• Maybe use 1/100 mm instead of inches as that is a standard outside the US? All US systems can also be defined with mm/100.

Of course. I grow up using the metric systems and I am naturally repulsed by imperial systems. It's totally fine with me if we use inches everywhere in the source code. But, the reason why I chose to use inches for the two US formats we currently support is because the users who own those keys are likely to be living in the US. If, in some use cases, they might want to look into the saved files and make the keys themselves, it's easier if we give US users inches and users from sane measurement systems millimeters.

If we don't give the user anything in physical units in the saved files, but some hyperlink or database index to direct them to necessary info, then I have no objection in using millimeters in the source code.

• With that a universal mode where the user can move pixel-by-pixel and save positions. Instead of bitting a 1/100 mm values for depth and spacing would be saved/shown

This is actually just an image drawing app. I think the app is already in the app store.

What do you think? I know that is a hell lot of work but worth it. If you agree to at least part of this, I would be motivated to work with you and learn the basics of Flipper development :D

Totally! Let me know which of these things you proposed you would like to work on. If you wanna work on the code, I'll try to help you understand what I've written. Or if you want to focus more on the locksmith side of things, just dump files and readings here. I love learning. Or if you wanna add more things to key_format.c and saved file formats, feel free to fork this repo and add stuff and then PR. And if you prefer a more rapid back-and-forth, join the discord page so we can chat there.

[santomet]

Glad to see that I did not discourage you :) Let me give you a quick course. So let's dive in:

Terminology

• Mechanical code or Bitting or Direct code is a code that defines a cut key based on card.
• Code - to make it more confusing, there are also key codes. Typicall, these are engraved on keys, locks and security cards. Sometimes the code is the same as direct code, however, in most cases you would need a database to find out the direct code from the code.
• System is a set of "rules" about the actual semantics of bitting. So where is the stop, how far away from the stop is the first cut, where are the other cuts, what are the possible depths, what is the cutting angle, what is the cutting width...
• Card is a way to define the system. The name is a legacy from old key-cutting machines like HPC Blitz where you inserted an actual paper card and aligned the machine's hands with ticks on the card to cut the key from code. However, modern key-cutting machines still use the term "card" for a particular dataset which defines a particular system.
• Profile or keyway is a profile of the key - the point here is that you should not be able to insert a wrong key. While in the US the most popular by far are KW1 and SC1, there is a great diversity in the world. You see, these are profiles, not formats or systems. Only that in these particular instances, if you see a KW1 key, it implies that it is of a standard Kwikset system/card.
• Stop is a part of the key that stops it in the right position when you insert it. On classic key, the stop is at the bottom of the blade and is called a shoulder, however, there are systems in which the stop is on the tip or near the tip, and therefore their cards are defined based on the tip instead of the shoulder. For example, FAB 200 RS/RSG: You can see that it ha no shoulder. It is because the stop is a little cut near the tip. The OEM specification is defined by that stop:
  
  However, to actually cut the key in a key-cutting machine, the specification in a card is aligned with the tip instead because it is much more simple:
  

About cards

You see, there are multiple manufacturers of key-cutting machines and all of them are using their own card numbering. However, we can say that Italian Silca has by far the most comprehensive database and is the most available. Sadly, cards are not publicly available for free. However, there is a cheap way to get these data - InstaCode by WH Software. In there, you can also find Silca card numbers. InstaCode can also help you find direct code from code. InstaCode has its own numbering, however, Silca is much more up-to-date.

About how to load the system in this app

Therefore, what you call a "format" now I would call a system or card. I think that the idea of loading systems (not already measured keys) by folders is important because there are countless manufacturers and some of these have more than 30 systems. And if we want to create a bigger default database of different systems, that is the best way to do it. So just to clarify, how the user saves his already measured key is one thing, but how he configures an actual system for measurement is another.

That's it for now. If I missed something or you have any other questions. When I get some more free time, I will start looking into Flipper development.

[santomet]

So, that said, I propose the following file format for defining the System.

Reasoning:

• Using standard locksmithing terminology
• We do not need to know MACS and Clearance or any other details. These are even very often unavailable data.
• Some systems can not be described implicitly by counting up the depths and spaces. Instead, we should explicitly combine mechanical code with a particular cut depth and provide explicit distance from the stop for each cut. This way we can have irregular systems covered and also the ones where depth decreases with number.

This example is the same as what you call KW1 Format right now:

Filetype: KeyCopier System Format
# All dimensions are in 1/100 of mm
Version 1
Manufacturer: Kwikset
System: Corbin Russwin K Class 5-Pin
Card_Silca: 403
#Stop can be Shoulder or Tip 
Stop: Shoulder
#Side can be One or Double
Side: One
Blade_Width: 850
Cut_Width: 200
Cut_Angle: 90
# Dimensions from the stop in order of the direct code, separated by space
Cuts: 627 1008 1389 1770 2151
# Final width for each depth, combined with direct code, separated by space, in format [Direct Code]:[Width]
Depths: 1:836 2:777 3:719 4:660 5:602 6:744 7:485 

[Zer0Cool88]

I saw this app pop up for my flipper and really loved the concept. This little project definitely has a lot of potential. I've been a locksmith for about 12 years now and dabble in programming a bit here and there as a hobby. I'd be happy to contribute some depth and spacing data that's publicly available online in order to expand the capabilities of this app. But that seems like a lot of work to REALLY expand it. The common user for a flipper won't likely use this for anything other than a KW1, SC1, SC4, and maybe a Y1 or S22 1/2, possibly a DE6... I can definitely give you an idea of the more commonly used keys and build up the prebuilt list... But I think the app itself would stand to benefit more from giving the user the option to create additional "custom" DSDs (depth and spacing data sheets) for the keys they work with frequently, in other words, let your users put the work in finding and importing that data into the app. It would give the app far more potential with a fraction of the work. I'll be honest, I'm out of my league with C+ lol I never liked it as a programming language and have avoided learning it for a long time. I cloned the repository and went through the code though, I probably couldn't rewrite it if I tried but I did take note on "key_formats.c" the way this info is being called in for the app. Is it possible instead to create individual profiles for each blank type to import the variable data for each in the app as selected from the menu and also create a sub menu that would generate these profiles based on the format used in key_format.c, or alternatively could the app compile and write that information to the key_formats.c file? I think that'd be the way to go vs actually going through and hunting down DSD info for all the different keys available out there. I could see this working pretty well with a lot of automotive keys too with a few tweaks. Like I said, I'm no good with the programming language these things use, or I'd have already jumped on a lot of this myself lol Best solution I could come up with was copying the block of code containing the info for one key type and changing all the variables to that of whatever key I'm adding in ( which tbh is a bit confusing because some of the terminology used in the code isn't what I'm used to in the industry) but then I got completely stumped like a noob because I've done zero developing with my flipper and have no clue how to update the changes to the app on my device lmao Hence me being like, "I wonder if I can get this dude to just let me add DSD profiles in the app so I can continue not knowing the C family of programming languages lmao I mean in theory you could use a spreadsheet file and put all the correct info in the all the correct places and have the application parse the info from there maybe?... IDK Hope this was helpful, lmk if you'd like help compiling further DSD info to write more keys into the stock version, though I may need a little clarification on a couple of the variables.

[santomet]

First, of course, hunting down all available cards is not meaningful, I too prefer personal customizations. That is why I proposed a very general format that can encompass almost any system. What might happen is that there will be a community effort creating card sets for each country/region.

Second, the world is much more than the USA and Kwikkset/Schlage. An average Flipper user can live anywhere in the world and in each country there is totally different market share composition.