| 18 Jun 2018 |
 Maximus | and I can definitely see those pictures and audio being edited often, as they would be the content itself | 17:04:05 |
 classywhetten | Is there a tool or framework that you'd recommend for pictures and audio then? | 17:21:59 |
| Maximus | I would have to look, I'm not aware of one - I think it's one of the challenges of now | 17:23:18 |
| Maximus | but maybe a version control tool is not the right fit itself. maybe something more CRM based that can easily deal with binary diffs | 17:23:46 |
| classywhetten invited  monicalwhite. | 17:26:36 |
| monicalwhite joined the room. | 17:26:40 |
| classywhetten | monicalwhite: Welcome to the group! | 17:27:49 |
 art|code | Maximus classywhetten are you guys familiar with ResourceSpace? open source media asset management software | 18:38:26 |
| art|code | https://www.resourcespace.com/ | 18:39:10 |
| Maximus | never heard, will check | 18:39:36 |
| art|code | Also classywhetten this may not be good news but ideally the system would be able to store and display video assets as well. | 18:41:23 |
| art|code | monicalwhite: welcome! | 18:41:42 |
| Maximus | oh boy, video too eh | 18:42:18 |
| Maximus | definitely not git then | 18:42:23 |
| art|code | maybe there is a way to just store links or pointers to a separate file system? | 18:45:17 |
| art|code | We have some experience forking/customizing ResourceSpace. Although that was the version from 5 years ago. Unclear whether they now support video and audio. | 18:47:55 |
| Maximus | yes, even tho you definitely want to avoid de-duplicating content that doesn't change. The real question is: how much will not actually change once encoded | 18:49:48 |
| Maximus | I don't know much of the impact of encoding of media upon the change accross the file | 18:50:13 |
| Maximus | I would think one small change would lead to changes all the way up to the end, but maybe "change" doesn't make sense that way. Maybe each iteration is actually to be considered an invidivual, standalone piece | 18:51:05 |
| Maximus | that's more a question for you guys, as creators | 18:51:11 |
| art|code | yep, and it's unrelated to the federation part. | 18:51:50 |
| art|code | my guess is we have a changelog and store the most recent version of each file / archive the rest | 18:53:12 |
| art|code | I don't have a clear sense of the schema for the data yet, but key would be making it easy to download / fork current resources -- approving new contributions (pull requests) would not be automatic -- and performance lag to access older versions of the same resource would be acceptable. | 18:55:22 |
| Maximus | I see | 18:55:57 |
| art|code | In terms of the benefits of federation, I would basically see resilience to network outages / server failures and resistance to censorship. | 18:56:10 |
| art|code | perhaps store thumbnails in Git -- full multimedia files elsewhere | 18:56:43 |
| Maximus | so each item should be considered as a whole, instead of an incremental set of change. The meta-data about the item should be the incremental change - am I getting the idea right? | 18:56:50 |
| art|code | yes | 18:57:21 |
| art|code | that makes much more sense with image data and the way it is processed during editing | 18:57:52 |
| art|code | I want to be able to say "added wings and drop shadow" to Illustration 3 -- the byte order doesn't matter | 18:58:44 |
