Update ActivityPods report

docs/activitypods.md

@@ -35,15 +35,17 @@ Besides the [limitations](#limitations) in their current implementation, I've al
 
 Most of these are likely to be fixed in a future version when ActivityPods becomes fully spec-compliant. But I was surprised because some weren't listed in their [official compatibility report](https://activitypods.org/specs/solid).
 
--   [Inrupt's authentication library](https://github.com/inrupt/solid-client-authn-js) doesn't work. I have to assume this is because they don't fully support Solid-OIDC yet, but I haven't dug any further. This may prove a challenge for some apps, but in my case I had already decoupled authentication methods so it was only a matter of [implementing a new one](https://github.com/NoelDeMartin/ramen/blob/main/src/auth/ActivityPodsAuthenticator.ts).
+-   [Inrupt's authentication library](https://github.com/inrupt/solid-client-authn-js) doesn't work. I have to assume this is because they don't fully support Solid-OIDC yet, but I haven't dug any further.
 -   Container urls don't end with `/`.
 -   RDF documents can only contain triples for a single subject, which has to be the document's url. They cannot contain fragments such as `#it`.
--   Document container urls don't match the document's. For example, using this app you'll notice the container for recipes is created at `/data/schema/recipe`, but child recipes are created as `/data/{uuid}` (instead of `/data/schema/recipe/{uuid}` as I'd expect).
--   Creating documents with `text/turtle` doesn't work, I had to use JsonLD.
+-   Document container urls don't match the document's. For example, using this app you'll notice the container for recipes is created at `/data/schema/recipe`, but contained recipes are created as `/data/{uuid}` (instead of `/data/schema/recipe/{uuid}` as I'd expect).
+-   Creating documents with `text/turtle` doesn't work, I used `application/ld+json`.
 -   It's only possible to create containers for known vocabularies. During registration, the server validates the vocabularies against [prefix.cc](https://prefix.cc/). For example, in my app I was using `https://schema.org/Recipe`; but that didn't work since it expected `http://schema.org/Recipe` (starting with `http://` instead of `https://`). However, once the container has been created, you can store any resource inside (for example, I also create `http://schema.org/HowToStep` and `https://vocab.noeldemartin.com/crdt/Metadata` documents).
 
-Depending how you've implemented your Solid App, some of these can be very difficult or very easy to bypass. In my case, I was able to make most of them work with relatively little work (take a look at [the diffs above](#current-status)). However, they create some issues that wouldn't be so irrelevant in a real application.
+## Conclusion
 
-For example, the limitation of creating an individual document for each RDF resource causes serious performance issues. In this app, you can already see how "learning Ramen" is much slower than against other PODs. Among other things, this happens because just creating a single recipe requires 13 network requests (1 for the recipe itself, 1 for the metadata, and 11 for the instruction steps). In a real application, like [Umai](https://umai.noeldemartin.com), this would be much worse. Besides having more than a single recipe, modifications also create multiple [CRDT operations](https://vocab.noeldemartin.com/crdt/Operation). Subsequently, this will become a problem each time the application wants to synchronize the data with the POD, because now the "recipes container" will contain hundreds of documents (most of which aren't recipes), which translates to hundreds of network requests.
+Depending how you've implemented your Solid App, some of these can be very difficult or very easy to bypass. In my case, I was able to make most of them work with relatively little work (take a look at [the diffs above](#current-status)). For authentication, I had already decoupled the functionality; it was only a matter of [implementing a new authentication method](https://github.com/NoelDeMartin/ramen/blob/main/src/auth/ActivityPodsAuthenticator.ts). And since I'm using the Active Record design pattern with [Soukai](https://github.com/noeldemartin/soukai-solid), I didn't have to modify most of my application code.
 
-Because of these, and other issues described throughout this document, I'm refraining from adapting any of my real apps to ActivityPods.
+However, there are some issues that wouldn't be so irrelevant in a real application. The limitation of creating an individual document for each RDF resource causes serious performance problems. In this app, you can already see how "learning Ramen" is much slower than against other PODs. Among other things, this happens because just creating a single recipe requires 13 network requests (1 for the recipe itself, 1 for the metadata, and 11 for the instruction steps). In a real application, like [Umai](https://umai.noeldemartin.com), this would be much worse. Besides having more than a single recipe, modifications would create multiple [CRDT operations](https://vocab.noeldemartin.com/crdt/Operation). Subsequently, this would become a problem each time the application wants to synchronize the data with the POD. Because now the "recipes container" would contain hundreds of documents (most of which wouldn't be recipes), and that would translate to hundreds of network requests.
+
+Because of this, and other issues described throughout this document, I'm refraining from adapting any of my real apps to ActivityPods. But I'm looking forward to the day they are addressed. Because like many others, I'm very excited about the project!