lajackson wrote:The Forum will follow the policy the Church determines for us. An example I enjoy sharing is that we have been asked not to give out the meetinghouse WiFi password, even though it is widely available to those who seek it.
Your LDSAccess WiFi example is actually a great illustration of how API access should work -- it's there, and you can use it if you can find out how, but it's not publicized
("Public but not publicized.")
I am glad this is finally being addressed, but I'm starting to think that forgiveness would have been better than permission -- I only posted publicly in the hope that having the info out there would help others.
There has to be a model that can address the needs of local leaders for information processing capability while aligning with Church policy, protecting privacy, and maintaining control over data dissemination. This could be either a technological solution -- something like how FamilySearch allows data access to third parties through OAuth -- or policy-based, for example
allowing use of the API to retrieve, display and print data, as can be done through the browser at lds.org, but not allowing anything other than member IDs to be stored locally on the API-user's drive. This would allow for the creation of things like Ministering management applications, where the mapping of member IDs to the IDs of their Ministering Brothers and Sisters is retained on the local server, but the contact details and callings of members are not stored locally. Every time you start the application and want to display contact info for members, you have to connect to the REST API to download the current membership contact info for display, and it is only ever stored in RAM, it is never allowed to hit persistent storage. Applications using the API would not allow for an electronic copy of the data to be saved, sent, copied or disseminated in any way, other than through the print / PDF generation option for reports. This would keep the exact same fence around the data as currently exists on lds.org, but it would allow sufficiently motivated leaders to move the fence so that it surrounds their own custom applications.
Is this a reasonable compromise? Whoever is working on the policy statement about the use of the API,
please carefully consider the above suggestion before you finalize the policy. The above suggestion would actually fall in line with usage of data in other places, e.g. in the LDS Tools app, which forces you to re-sync frequently, so that the church maintains power of revocation over data.
It is critically important for the church to allow local leaders to figure out the best way to minister to their local congregation (Isa. 54:2 "spare not, lengthen thy cords, and strengthen thy stakes" -- the Church has to move in the direction of giving more autonomy to stakes and local units, if it is to fulfill its purpose). Please don't issue a blanket statement shutting leaders out of data usage outside of using the UIs of lds.org and LDS Tools -- they are highly inadequate for a number of important use cases, as evidenced by the number of local leaders who over the years have dreamed about and asked about getting data access so they can build something better. We technology-interested saints currently have no way to directly contribute to the development of these systems, since they are not open source.