diff --git a/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md b/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md
index 8a22640..0c9d224 100644
--- a/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md
+++ b/Developer-Path_Implementing-Commons-Using-ActivityPub-Groups-and-Hashtags.-.md
@@ -19,6 +19,8 @@ We likely don’t need traditional “groups” in the Facebook sense. Instead,
 > [saunders]: I feel like this might be confusing. Do we not need to define "group" with regard to members that come from one or more instances.
 > Also we should acknowledge that we're almost certainly using "group" in a different sense to what other fediverse implementations are working on - do we want to find a different term, or try and broaden an existing one?
 
+> [hamish]: yes i would use the word "**flow**", but am getting confused too with the word and implementation of group
+
 #### Q. Is each object still owned by a user? (for federation reasons?)
 
 ...but logically "shared" with others via inclusion in a "commons group".
@@ -33,6 +35,8 @@ If so, the group becomes an object itself - recursively building a metadata mesh
 > Then much like a multitude of replies to a single toot in mastodon can be displayed as a thread in the UI, we could (re)construct a single document to display based on the thread of diffs.
 > Am I getting too deep into the weeds too early?
 
+> (hamish]: interesting
+
 #### Q. Collections & storage?
 
 Collections are part of the core ActivityPub spec, but vague in meaning.
@@ -54,10 +58,14 @@ Metadata & hashtag logic, hashtags act as the primary organizing mechanism. We a
 > [saunders]: Not sure how to go about this. Injecting hashtags feels a bit off. They would have to be somewhat separate from normal hashtag use, but then other fediverse instances would not recognise and them as normal hashtags...
 > But if they're intended only for "internal" use and not really for more convential use by e.g. a mastodon instance, then I think it would be fine to store them separately.
 
+> [hamish] maybe we can use the same space but put a different symbol in front - meta data tags - the same function just added by rules not people.
+
 #### Q: Do we need a better metadata field than hashtags? Or can we repurpose hashtags in a way that supports this abstraction?
 
 > [saunders]: Going on my comment above, I feel like maybe we just use a separate field.
 
+> [hamish] they have exactly the same function, so for cross federation, we don't have control how they are displayed or used so might as well just show them all.
+
 Trust & authorization flows, only people in a trusted group can edit an object in the commons. Others can view/comment but not edit. Trust flows are likely to diverge into subjective consensus spaces - and that’s fine.
 
 > [saunders]: We need to clear up the ambiguity between group as a set of people vs group as something determined by a set of hashtags.
@@ -68,6 +76,8 @@ Templating & UX abstraction, hashtag chaos needs to be hidden (mediated) in the
 
 > [saunders]: Feels like another reason to use a separate data field, and not whatever is currently used for hashtags. That said, we may still make use of normal hashtags for some filtering, as they usually are.
 
+> [hamish] the is a difference between category and hashtag, one is vertical one is horizontal, we do the horizontal, even if its a bit of a bodge. https://hamishcampbell.com/federating-metadata-flows-bridging-folksonomy-and-categories-for-the-omn/
+
 #### Q: Can templates be federated or instance-local?
 
 > [saunders]: "Template" in the `emmisary` context? Or other?