My introduction to LightNet
The LightNet vision originated from David Fry. Initially, when Wilma (my wife) joined MediaWorks I had no intention to also join. I wanted to work in Vienna. Speaking with David, I learned about the vision of LightNet, at that time called MediaHub and later Media Exchange Platform (MEP). I became enthousiast about it and over time I joined MediaWorks too.
One core idea that was shared at that time was a graphic which contained a funnel where media of many sources were put in to and then curated media came out that was used by VCJFs (Vibrant Communities of Jesus Followers). The curation happened with filters on the data. Time based, license based are some of the filters I remember.
David explained in that time that a previous system was built within Trans World Radio. This was a system that was built on top of Azure. One of the stories he told was that ministries were hesitant to put their media in it. Also it felt strange to the ministries that they would be sharing data and then had to pay for it. It might have felt as if they were losing ownership. He also told that this was a very expensive system, to create and to run. Another interesting problem was the fact that Christianity is fragmented into many denominations. Some organisations did not want to join the TWR system if other denominations were also in it.
I told about OpenGroup, a peer to peer system (prototype) I had built. I also was (and still am) passionate about decentralized systems and heavy client side applications. I do not remember clearly if I shared this with David, but I did think that decentralization could be a solution to the problems that had happened in TWR. It would also spread out the cost better.
The core idea from David at that point was, can we somehow create a place where media from many sources / ministries is gathered so that we can strengthen Christian communities. This media can then be exposed via apps towards Christian communities or seeker audiences. The main customers were ministries that do have contact with a local context. They want to spread the gospel and an app can support them in doing that. We would create the place where the media was gathered and the apps on top of it.
The system within TWR had a very generic front end. The front ends were native mobile apps. Very audio focused and also very series focused. Jamie can tell more about this as he has been working in the TWR context too. You could add a logo to it and add your media. Visually these front ends had a bare minimum user interface.
The development of the vision
When I joined MediaWorks I came into contact with RDF. I had this idea of decentralization in the back of my head and looked into technology which could support decentralization and do the data modeling. Data modeling in a decentralized way seemed quite hard to me. Who maintains the standard? Can organisations structure data as they like, or must they subscribe to standard properties?
RDF
RDF has a concept called federation. It is able to do queries over multiple sources at ones. These sources do not need to know of each others existence. A good example that showcases this is Comunica demo. Comunica is a RDF query engine. It can query over databases, web pages, and various other data formats. This federation became a big topic in my thoughts about the architecture of LightNet. Would it be possible to give each organization their own MediaHub and still do queries over them? Would it be possible to create little mesh networks? This would also solve the problem of the association of denominations as organisations would only be connected to other organisations they like.
This would mean more autonomy towards the organizations as opposed to the TWR situation where there was only one system and everyone would be somewhat associated with each other and they would put all their data in one place.
In the months before joining MediaWorks I started work on RDF-form. A system that easily creates RDF based forms according to a form definition. In this same time Jamie was working with MediaWorks. They started with Moodle and wanted to create the MediaHub system on top of that. I was critical of this, I thought the data modeling would not match.
In the beginning of joining
In this time OttBusch had conversations with the team, I joined at least one call. The initial idea was that they would develop the MediaHub system and I would join them. The idea was to do it this way so that we would have a very stable product made by a team of experienced developers (they had built the TWR system). Ultimately this did not work, there were not enough funds to pay them. At the beginning of this working together OttBusch and I were asked to look at ResourceSpace, the idea was similar to Moodle, to create LightNet on top of that. I was critical of this.
Jamie and I started to work together and I quite pushed my ideas. It was a difficult position to be in. For Jamie and for me. Jamie had started the project with Moodle and I was very skeptical of that as a firm base to built on top of. Jamie started this as a pragmatic way of making progress (I think). The RDF stuff was somewhat new to me and totally new to Jamie (if I remember this correctly).
Some background information
We also had quite some tensions, Jamie coming from a background where he was a Systems Architect and me coming from a culture were Systems Architects were to be integrated into the team as some sort of a coach without much power. I was the only one that wrote code at that point. At an early stage I had communicated that working alone on the code was not really a good option. Later Clayton joined and we got into a little better space. Anyways I digress, but I do think it is important background information.
My personal vision has somewhat developed in me over time. Finishing version 1 showed clear short comings in what I had made. The initial page load time was huge. I had modeled the RDF without strong database constraints. RDF is free form. In its core there are no database constraints. Similar to NoSQL. I learned about SHACL and started investing time in this. SHACL is a language to give data constraints to RDF. The custom made translation of RDF to JSON also took its toll. The page loading time was a combination of many factors that could be improved.
So over time I started working on a version 2 that had SHACL in its core. I wrote SHACL form a form builder similar to RDF form but with SHACL at its core. I got into contact with Thomas Bergwinkl and together we started a community working group: SHACL UI under the W3C. I met many people who worked in this space and I felt my ideas and vision validated by them. Of course it can also be that this was just a group of nerds together that had lost track of pragmatic solutions. Anyways in this group we were looking to standardize SHACL usage for user interfaces. In my prototype for version two I had built a concept called ViewModes which was very similar to the ideas that people had in the SHACL UI community working group.
So my personal vision developed, but did we reach also agreement? Jamies vision was more pragmatic than mine and also a bit smaller. One strong disagreement we had was server driven UI. I think Jamie was at peace with using RDF at this point. We had diverged on the vision for LightNet. To get back on track, Jamie had started working on Non-technical requirements. This been a long process with its own tensions. I agree with these fully in the state that they are currently in.
Somewhere in this period Simon joined the team. In the beginning I had the impression that he shared the vision or at least agreed on the fundamental ideas. Over time it became clearer that he was unsure about the vision. And to be fair there is no business plan available to look in, there is no up-to-date clear cut road map available or an architecture design that specifies implicit things that I took for granted.
The first month we worked on knowledge transfer and I tried to explain the RDF ideas to him. In this month it became clear Simon did not like the RDF technology. He found it too complex and it was not clear for him which part of the vision it solved. He wanted more concrete problems and solutions.
Slowly we talked about replacing the RDF and SHACL with JSON and JSON schema. I do like these ideas. The code we currently have for version two is much faster and smaller. I do have concerns about the bigger vision. Simon is not agreeing we should have server driven UI. I have agreed to skip this for now and first have it hard coded in the front end. From my end I have tried to make sure that it would still be possible at a later stage.
So what is that later stage in my mind?
My vision for LightNet
I believe LightNet could be a storage box for Christian organisations to built anything on top of. The core fundamentals would be:
- media meta data
- the media files (for media owned by the organization)
- users
- groups
The core (backend) would be agnostic to what kind of media data would flow through the system. If a church would want to create a liturgical prayer app that would be possible, just define the data model and the data views and it would be possible to use in the generic channel viewer. If a church wants to have a different visual identity for their app they can use the SDK to create their own app. Specific apps such as a liturgical prayer app could be using LightNet as a data store. It would give developers super powers. It would give churches super powers. Imagine that for your church you can just re-use a prayer app and fill it with your church prayer points each week and a selection of prayers that you like.
My vision would be that the global church unites on building great apps on top of this. Very specific apps that serve one goal. But underneath a framework, backend and SDK that is more generic.
The generic front end would be media centered, a small Spotify or YouTube for their community. Inside there would be ways to engage with the media, ways to have bible study groups round a certain theme. There would be groups so that you could repeat a bible study with a different group of people and have a new round of discussions on the same media.
LightNet could grow out to be the standard solution for Christian communities. On top of the distribution ‘engagement’ features can be added. The logic of these would live in the SDK as the backend is quite agnostic.
Non-technical requirements
When this would be done within the context of the Non-technical requirements a system could grow that over time would have federation and could easily help small groups of Jesus followers in least reached regions to find media in their language from sister churches. It can enable a simple way of distribution bible studies from an organisation to a church. It could distribute eBooks from MediaWorks to ministries that then use it to spread the gospel.
Ultimately I envision LightNet as a tool to create small media focused communities with a data model that encourages sharing. Next to the sharing of data it could grow out into a ecosystem where Christian apps are re-used, such as the idea of a record-my-sermon.com where an audio technician navigates to record-my-sermon.com, logs in with their LightNet and the recorded sermon would automatically be stored in their LightNet in the right place so it would show up in their sermon archive and possibly also in the shared sermon archive of the church and their three sister churches.
Solid
This vision is very similar to Solid, the project of Tim Berners Lee to ‘fix’ the internet. Summarized very small: Solid offers a data vault per person and applications do store data in these vaults. You could use multiple calendar apps and manage events in both of them. The data would not be locked in to one vendor.
My ideas of LightNet are similar to Solid but instead of one data vault per person it would be a data vault per organisation / church.
There would be group systems where different people can have different roles. That way it would be quite easy to build communities on top of LightNet.