https://familysearch.org/developers/docs/certification/authentication

Authentication Certification Checklist

Authentication certification applies to all applications that access FamilySearch resources.

The following checkbox items are required as specified in order for your application to obtain Authentication Certification.

All Applications Requirements

• Each user must obtain a FamilySearch access token in order to read or write to the Family Tree.
• Access tokens must be protected. If a user access token is passed to a web browser in a cookie, that cookie must be a secure cookie. All cookies that give a user the ability to use an access token must also be secure cookies. Mostly N/A
• Network traffic is encrypted with SSL from the end user to the FamilySearch API.
• User authentication is completed by directly calling the FamilySearch Third-Party User Authentication web page using OAuth 2 as specified by the Identity Authentication documentation as follows. (Me interjecting here: This is from documentation that needs to be updated: what's crossed out at the beginning applies to Web signing-in only, and the latter that is crossed out is the name of the old endpoint.)
  • No storage of FamilySearch usernames or passwords is permitted with web applications. N/A
  • FamilySearch Person ID numbers can be stored by the application.
  • The FamilySearch session cookie must be a secure cookie. N/A
  • No permanent storage of FamilySearch API Session ID is permitted.
• Refresh tokens can be used for selected confidential clients determined on a case by case. This capability is implemented through the use of a service account. N/A
• Have a documented security policy, which is periodically reviewed, is approved by management, and is communicated to all employees. (Me interjecting here: We need clarification on this. This may apply to just "confidential" clients and/or closed-source projects...)

Desktop and Mobile Applications Requirements

• An embedded web browser can be used to call the FamilySearch Third-Party User Authentication web page if the URL being called is clearly visible. N/A: Going to use desktop login
• Native Apps must request acceptance to the following information:
  • [Product Name] would like to know your basic FamilySearch profile information and access data about your ancestors from FamilySearch family tree.
  • [Product Name] will use this information in accordance with their respective terms of service and privacy policies.
• Desktop Applications may store passwords locally using 128 AES Encryption. On iOS, Apple Keychain is acceptable.

Sorry if this is not the right place to post this question, but can this be used to import FamilySearch Trees to Gramps, now? Is it ready to be used? If so, how do I use it? Didn't see anything on the wiki..

Thanks.

https://familysearch.org/developers/docs/certification/sources

Sources Write Certification Checklist

Sources Write applications give users the following capabilities.

• Create new sources
• Attach Sources to Persons
• Update Sources (Edit, Delete, Detach and Compare)

The following features are required for your application to obtain each of the three Source Write certifications.

Create Sources Certification

• Read Certified
• Use the Sources API resource calls to read and create sources to persons.
• When creating a source, give the user the option to enter the following information. Only the Title is required for the source to be saved.
• Title (required)
• URL
• Citation
• Notes

Attach Sources Certification

• Create Sources Certified
• Use the Sources API resource to attach sources to persons
• When attaching a source to a person, allow the user the following options.
• Enter search parameters or person ID to find and select the person to attach sources to.
• View the person Name, person ID, birth date, birthplace, death date, death place, parents names, and spouses names if available in the results of the search.
• Set event tags such as name, gender, birth, christening, death, and burial for the source.
• Enter a reason that the source is valid. Reasons are not to be used to promote the partner or partner products.
• User Interface Requirements are to make interfaces substantially similar to the following:
• Search for Family Tree persons ID
• Associate a Person or Artifact in a Third-Party Application with a Person in FamilySearch Family Tree
• Read and View Sources Contributed by the Authenticated User
• View Sources through FamilySearch Family Tree Person Page
• Create a Source
• Attach an Existing Source to a Person

Update Source Certification

Note: To update, delete, and detach sources requires Tree Write Certification

• Attach Sources Certified
• Edit Sources
• Detach Sources
• Delete Sources
• Compare Sources
• Mechanisms in place to prevent duplication and preserve data integrity.
• Prevent duplication of a Source on the same partner-FT connected Persons - The Partner tracks the SrcID while on this Partner person. The partner app should capture the SrcID when they copy an FT Source or Create a Source
• Preserve the Source data integrity - Capture Source conclusions and SrcRef Reason and tags.
• Maintain connected Person/Source integrity - So before a partner user can edit a Source that came from FT on that connected Person, the user must see the current FT Source values.
• When a Partner creates a new FT Person - any Sources created are attached to that FT Person. Those Sources have no dup issues on a new Person.
• At the point of connecting Person between FT and Partner (not from an Add Person workflow) no Sources flow across to FT. The user can push-pull to attach specific Sources. A connected Person that has a subsequent Source attached/detached on the FT side may or may not show up as the Partner Person side.

Options

• If you pre-populate the reason, make users aware of where and how to explain a reason if they decide to change it.
  See the results of additions and attachments in FamilySearch in order to edit, or undo.
• Create, access and otherwise manage source boxes.
• When Creating a Source for a previously created memory, enable the following:
  • Search and view all memories that were contributed by the current user.
  • Create a source using an uploaded photo or document by using the Memory module API resources. See the how to for Create Source With Memories example.
  • Allow the user to enter a source title, citation, and note by using the Source Descriptions API resources. See the Create Source Description example.

OK, I realize this may not be the best channel for all, but it's currently the best one for me...

I've got the repo. I've got a good number of GRAMPS devs I can talk to. I've (somewhat) got the coding skills. I've got a bit of time. I've got a fully-functional FamilySearch-Python SDK. It sounds like we're going to get the get-go approval, even if it's only read-only access at first.

What I lack are a solid gameplan and a grasp of PyGObject (or whatever GRAMPS uses for its GUI).

I can throw some ideas as edited screenshots in here.

I've currently slapped the BSD license on the repo, but I'm more than willing to change it to GPL.

(As a side note: The reason I chose BSD for the SDK is to allow it to be compatible with the GPL, yet allow other developers to, if there's some agreement between FamilySearch/boss/school/whatever that requires the app that integrates with FamilySearch.org to be closed-source, it's available. A bit of a compromise, I know, but I felt it necessary.)

I don't know if I'll be able to contribute code any time soon, but expect some screenshots soon!

I'm now undecided:
Should we use folders, or branches, to separate each GRAMPS version?

I know I've set up branches, but I'm feeling that it may complicate things in the long run....

It seems like the next step for integrating Gramps with FS is to write functions to go back and forth between Gramps and FS. Gramps has two serialized forms:

1. a Python tuple-based raw form, eg, person.serialize(). This is the internal format stored in the database.
2. a JSON-like dictionary-based form, eg, person.to_struct(). This is used for queries and diffs, etc.

The second form may be easier to deal with, especially as time goes on, because it can be immune to some variance in the data format.

Likewise, you can create an object from either form. In the serialized case, you need to construct the all parts exactly (Person.create(data) where data is a tuple-based form). I believe that the JSON-like format will fill in default values (Person.create(Person.from_struct(data)) where data is a JSON-like struct).

So, I suggest methods that can take a FS result and convert it to a Gramps struct, and a Gramps struct and convert to FS JSON.

https://familysearch.org/developers/docs/certification/memories

Memories Write Certification Checklist

Memories Write applications give users the following capabilities:

• Upload new memories.
• Edit memories and create personas, comments, and sources.
• Delete and detach memories.

The following features are required for your application to obtain each of the three Memories Write certifications.

Upload Memories Certification

• Authentication certified.
• Users can upload memories (unattached or attached to a person).
• The upload agreement initially must be displayed and accepted by the users.

Edit Memories Certification

[ ] Read certified using at least one Memories read API.
[ ] Upload Memories certified.
[ ] Edit the titles and descriptions of memories they created.
[ ] Create personas of people in the tree on memories that they created.
[ ] Create comments to memories.

Delete Memories Certification

[ ] Edit Memories certified.
[ ] Delete memories that they created.
[ ] Delete personas that they created (detach from a person in the tree).
[ ] Delete memory comments.

Options

The following capabilities are not requirements, but you can include them:

• PDF upload.
• Audio upload.
• Create a source from a memory.

File Formats

FamilySearch.org accepts the following file formats or types (note that the maximum file size is 15 MB):

• Image: .bmp, .jpg, .png, .tiff
• PDF: .pdf
• Text: .txt
• Audio: .mp3

Discussion Write Compliance

Discussion Write compliant applications can list, create, update, and delete discussions and related comments.

The following items are required as specified in order for your application to obtain Discussion Write Certification.

• Read Certified
• Use the Discussions API resource to list, create, update, and delete discussions.
• Use the Discussions API resource to add, update, and delete comments.
• Use the Person Discussion References API resource to add, update, and delete association of a discussion with a person.
• Allow users to list discussions and comments in dialog form and to edit and delete them in a substantially similar way as found in the FamilySearch user interface.
• Allow users to comment on a post.

https://familysearch.org/developers/docs/certification/read

Read Certification Checklist

Read certification applies to applications that access FamilySearch resources in order to analyze, visualize, share, and publish the information. This includes reading information about persons, relationships, memories, photos, stories, documents, sources, discussions, and change history.

The following checkbox items are required as specified in order for your application to obtain Read Certification.

• Authentication Certified
• Demonstrate proper implementation of one or more of the following types of read operations.

Important! Each type of read operation listed below must be certified independently. Read certification for one type of read operation does not certify your app for any other type of read operation.

• Read Changes
• Read Discussions
• Read Hints
• Read Memories (by person, by user, personas, comments)
• Read Person (details, pedigree, portraits, or search)
• Read Sources (by user, or by person)
• Read Places

(Me interjecting here: I'm hoping for all to be eventually checked off.)

• Demonstrate proper handling of cache. If the data you read is cached, do not store it in local memory, purge the cache if the back button is used and at the end of your user session. N/A