Obligatory https://xkcd.com/927/

I (apparently) talked about this on the fringes of the conference about seven years ago:
https://hughbarnard.org/federated-apis/

As such my 'comment of the day', would be standards are a thing, adoption/implementation is another thing. There's a lot of inertia, TCP/IP beat X25 (I think) mainly because there was suddenly power at the edges in the form of PCs. So a new one usually has a very hard time.

I've restarted a little work on https://sourceforge.net/projects/cclite2/ as an anti-crypto demo (for one thing) and implemented MQTT via https://www.rabbitmq.com/ as an experiment. Lots of stuff possible with existing pub/sub.

Hi, I'm a frontend developer and am very keen to help build the PLANET app. Where do I sign up to do so?

@numblock you just did! :) I will send you a DM to discuss more...

In many cases, it might be difficult to imagine an app that doesn't yet exist? Could the approach to finding out what the groups need be different? Instead of saying we want to build this app, would you use it? Approach them and ask: "what digital problems do you have"? Or, in general, "what problems do you have" and then see if a digital solution can help solve those problems? The result may or may not be the same as foreseen or hoped for?

@Ivana I 110% agree with you. @Oli SB we really do need requirements from real stakeholders before we start specifying features. And I know that it does seem like an arduous task when everything seems very obvious. And, believe me, I feel this too – I'm speaking from my own experience. But building for collaborators from day one has really humbled my process within Kendraio and also made our app more relevant to real people, doing what they do, from day one.

@Ivana remember our group tools survey ? We did a huge amount of research ... and are feeding the results into our plan for PLANET ;)

Hi @Oli SB I love your graphics. Really easy to digest. Can I set up my own group? With my own group rules? What if I just want to do something on my own, can it be private? Can I have a private group? There's so much great features in the Planet app but can I use them if I don't want to share everything? I guess I'm wondering if there is enough freedom for the individual here. Am I free enough when using this app? Is the total stack (from tech to operations to philosophy) too fixed one way or can I change some part for me without having to ask for permission or get agreement from others? And does that make the whole thing a bit brittle? Cheers!

Thanks for the encouragement @Daniel Harris let me try to answer your excellent questions:

Can I set up my own group?

Yes, you can set one up on a hosted instance of PLANET, host your own instance of the PLANET code (for yourself and other groups) or use some platform / roll your own and adopt the same protocols

With my own group rules?

Sure, as long as you agree to the main principles and Membership Agreement of PLANET (TBD but essential agreeing that 'we rely on planet earth for our survival, therefore we put people and planet before profit, and default to cooperation rather than competition)

What if I just want to do something on my own, can it be private?

Sure, we imagine private groups coming in later phases - as the whole point of PLANET is collaboration, so private groups are not a key requirement

Can I have a private group?

as above

There's so much great features in the Planet app but can I use them if I don't want to share everything? I guess I'm wondering if there is enough freedom for the individual here. Am I free enough when using this app?

that's a hard one to answer without a definition of 'free enough'!! NB you may need to pay a small amount to cover hosting costs if you're on a hosted solution.

Is the total stack (from tech to operations to philosophy) too fixed one way or can I change some part for me without having to ask for permission or get agreement from others?

Not sure - this is a work in progress

And does that make the whole thing a bit brittle?

TBD but the main point here is that what we are trying to define is a set of protocols (which people can chose to adopt or not) and to implement them to provide a hosted solution for groups, which others can also install, or integrate with by using the same protocols - so members are not locked into one 'platform' or instance, so hopefully will feel free enough to want to collaborate with other people and groups in 'the network' / 'federation'

Hope this helps?

PS. This was meant to be the 'outreach' thread and this feels more like 'specification' so I may move these posts to the other thread.

@Oli SB thanks for your great answers! And I'm cool with you moving the thread. Yes, it does seem a little bit more like 'specification'. 🙂 By the way, I was thinking Planet was a standalone app but actually it's a hosted service. So, perhaps calling this the Planet Platform might be more appropriate? And now that I know this is a service, can we make sure that the communication between the user's device and the service is an open API? Or, if the app running on the user's device is just a branded wrapped browser, can we make sure that there is also an open API to the Planet server so that alternative interfaces can be created? By the way we are trying to make APIs mandatory for all websites, apps and services with our Kendraio API Law. Enjoy!

@Daniel Harris thanks for your thoughts on this - you made me realise that I have been trying to describe too much under the PLANET name, so I've now broken it down into: The PLANET Project, within which we are designing Protocols, Infrastructue and a Network, as detailed here: https://open.coop/planet/ hopefully this makes it easier to understand!?

And YES! There will be APIs - none of this will work without them... ;)

Thanks @Oli SB. This is getting clearer from me. But just so I understand totally, you want to build a service/website? This is not an app that can run offline on a device (phone or laptop) like Excel? This service is accessed via a web browser? All true in your view? Or are you not sure yet? And that's totally cool if you are not sure yet? We are all feeling our way. Knowing if these statements are true, false, maybe will really help me and others help you define the specification. But I want to be clear before I suggest stuff. Happy to have a call about this by the way. Cheers!

Hi @Daniel Harris good clarifying questions. Yes the MVP at least will be provide a way for Admins to host websites (or services, if you want to describe it like that) for groups of user members. It will probably be designed to be mobile first, and to be acccessed via a PWA. So, not strictly an app in the 'app store' sense, but still, an app experience for members. It may also be designed to be local first so that it is not reliant on a constant connection to the server and still works for people with poor connections... but all of this is still TDB.

Hi @Oli SB building an app as a PWA is totally legitimate and it is extremely common practice. Many of the apps in app stores are PWAs wrapped in native library that includes a browser. Apps in app stores don't have to be totally native but just wrapped in something that makes them look native. That's what we have in mind for Kendraio App too. I would also stress that the requirement of being able to operate offline totally changes the architecture not only of the local device app but also the hosted server software. So, knowing early in the design phase is essential. It's not something that can be bolted on later without a total rewrite – and expensive. And I totally support the Planet local device app being offline capable. It would be awesome! Are you going to the Local-first conference? I'll be there! I was in the second row last year. This year I have glasses so not sure which row I'll be in! 🙂

Hi All,

We just published our research into DIDs https://open.coop/2025/02/09/planet-research-decentralized-identifiers/ we think we may have found a suitable solution for PLANET in UCAN, but would love more thoughts and input on this. Selecting an appropriate ID system is clearly a foundational part of specifying PLANET so please do share your feedback!
In collaboration!

Oli

@Oli SB

We’re excited to hear about the reinvigoration of the Open Co-op’s PLANET initiative! My wife, Jennifer, and I have been developing a vision that closely aligns with PLANET—one that has evolved from a cooperative economic model I first envisioned in the late 90s while working on a transformative initiative for American Airlines.

In recent years, this vision has become increasingly user-centric, leading us to develop an open-source offers and needs app. More recently, we’ve focused on enabling small, close communities of care (CoCs)—designed around mutual respect and aid—to strengthen relationships through shared values and resources.

Introducing GoalPost

Last November, our Seed CoC came together in Greece to co-design and build the first prototype of GoalPost, an open protocol, open-source platform for community-driven collaboration. Like PLANET, our approach prioritizes meeting the foundational needs of our own community first, then iteratively expanding to broader communities in a way that embraces non-separability and regenerative values.

Using the Shape Up methodology (from Basecamp), we successfully completed our first GoalPost prototype in January. Our initial focus was on:

• Building a shared ontology & graph of core knowledge for seamless resource-sharing.

• Developing a Neo4J implementation & UX to facilitate intuitive navigation and collaboration.

• Prioritizing emergent insights from our user community to guide future iterations.

We are currently testing this prototype across two CoCs, and we’re already seeing promising results—particularly in how people engage with new connections and shared resources.

Potential Synergies with PLANET

We see significant opportunities for cross-pollination between GoalPost and PLANET. A few insights we’d love to share:

1. Sustaining Offers & Needs Markets – Our experience with open-source offers & needs apps revealed that initial excitement often fades unless resource-sharing is placed at the core of the UX. We shifted our ontology accordingly, replacing offers with resources and linking those to goals in a way that embraces needs, wants, desires, etc. We also introduced Care Points as a way to measure effectiveness. These are similar to the reputation features identified for PLANET, but focused more on mutual aid.

2. Leveraging Generative AI Without High Compute Costs – We’ve explored graphRAG with generative AI to reduce reliance on costly LLMs.

3. Enhanced Security & Distributed Identity – Given the sensitivity of community data, our approach to DID-based authentication and authorization extends beyond what we’ve seen in PLANET’s documentation.

Next Steps?

We’d love to discuss how we can best share our experiences to support PLANET’s mission. We could:

• Suggest open-source components that may be useful for PLANET.

• Share insights on semantic knowledge graphs & privacy-centric architecture.

• Explore how our graph-based AI approaches align with PLANET’s roadmap.

Would you be open to a call or a deeper discussion via DM? We’d love to find ways to contribute meaningfully to the PLANET initiative.

Looking forward to your thoughts!

Best,
Robert & Jennifer Damashek

Hi @RobertD - thanks for highlighting your work, which looks excellent and so aligned with PLANET we'd be crazy not to collaborate somehow! Let's aim to set up an open meeting which others can attend too (no point in having private DMs - at The Open Co-op we like to work in the open!)... perhaps once you have a version of GalPost which you are able to demo. Which time zone are you in? Feel free to suggest some dates / times to meet? (Mondays and Thursdays, UK day time work best for me - but lets go with whatever time suits the most people) We can use the Open Co-op BBB meeting room. Looking forward to hearing more.

I have also been chatting to @Grace (Rebecca Rachmany) who worked on a game around community sufficiency which feels related to your work, about which she said "...the purpose is to generate self-sufficiency and strong trust in a region. It's not to "fulfill needs and offers". In other words, it's a sufficiency approach rather than being based on marketplace conceptualizations of what needs and offers means.... The idea is that you might not get exactly what you need, but a lot more value is created by just sitting down and discussing how each group can help one another, rather than how do we simply exchange goods. For example, we can borrow a truck from a neighbor instead of buying it, or we could teach our young people to construct cars from old parts. Those solutions don't make sense for an individual or in a strictly defined trading system, but on a local level you start to expose resources and solutions that are otherwise unavailable."

I think this kind of interaction is a key part of the local groups we want to support with PLANET and suggested that "somehow we need to embed this thinking / practice into local group processes... perhaps it should form part of an 'onboarding guide' for new groups that express interest in using the PLANET O&W tools..."?

This also feels highly related to what Indra has also been working on with the CANS so we have lots of experiuence on which to build!

Both this community side of mutual aid / O&W / local groups, and the tech, are things we can discuss when we meet.

Looking forward to it!
Oli

@Oli SB We would love to have an open meeting in the Open Coop BBB! We are on US Eastern Standard Time (GMT-5). We are expecting to have a demo app instance installed and operational sometime this week, and Thursday’s don’t tend to work well for us. I would suggest we explore either the week of 24 February, Monday or Wednesday, 2pm GMT, or the following week of 3 March at the same time. We could do a demo and explore alternatives for collaboration with Planet.

The community sufficiency game sounds interesting to discuss as well as CANS. It’s also interesting to explore how small groups (ours are small but not strictly local) focused on mutual care might collaborate with a platform cooperative offering care-centered, regenerative (e.g., non-transactional) services.

We plan to apply AI for matching in a subsequent prototype, with an emphasis on matching semantics first (GraphRAG) to minimize the use of LLMs and their drain on planetary resources. This is likely a topic for a subsequent discussion, but I would point out the wonderful set of like-minded resources sponsored by Gesturing towards Decolonial Futures.

Thanks again Oli and look forward to meeting!

Robert and Jennifer Damashek

@RobertD  2pm GMT on the 24th works for me - see you then on BBB: https://de.meet.coop/oli-qef-zg3-r06 all welcome! :)

@Oli SB it's in my calendar! Cheers!

Hi All,

Just a quick reminder, we're meeting at 2pm GMT today to see a demo of @RobertD 's Offers and Wants system and to discuss ways of enabling communities with Offers & Wants in general, all welcome! :) - see you on BBB: https://de.meet.coop/oli-qef-zg3-r06

@RobertD that sounds interesting! I'm particularly curious about your offers/needs software, with resource sharing. Do you have links that would explain that more, or even a demo?

Also interested if there is more you can share about your GoalPost prototype? Thanks!

@Lynn Foster Thanks for your interest. Just to clarify, I’m wondering if you are interested in our earlier offer and needs app. If so, we have a demo version of that here. We also have an open source repository available here, and the ReadMe describes the project goals fairly well. However that software it is not under active development. It was built before we fully realized the issues with sustaining engagement in OANMs, and that resources were more important.

We do expect to have our demo version of the GalPost prototype 1 with test data available sometime next week, and are happy to arrange for a demonstration .

FYI @Lynn Foster @RobertD I have 45,000+ users signed up to my old car/ride share platform Freewheelers which we will soon integrate into Kendraio App as a Kendraio Pilot. And extend from cars/rides to other services. We will also integrate any other offer/request platforms (that have an API) into Kendraio App. Note that Kendraio App is a free, open source, personal, local-first, no-code app that enables users to aggregate similar services into their own personal dashboards. Also note that there is no requirement for any of the platform APIs to be similar. We create a bespoke connector for each service. Kendraio App runs on a user's device and connects directly to the platforms. There is no middle server. Kendraio (the team/non-profit organisation) does not take a cut of transactions nor have any view of the transactions. We are also experimenting with integrating to shopping systems so that users could build their own personalised Amazon. I think the Planet system will be an awesome part of the positive change ecosystem.

@Daniel Harris Thanks for sharing about Kendraio. I had noticed that with interest when first reviewing the PLANET threads. It seems like a wonderful initiative and the level of grant support you’ve achieved with it is marvelous! My initial review of the architecture in the Kendraio documentation leads me to question if it will support the core capabilities we have envisioned for GoalPost. I would be glad to discuss that further if you’re interested.

Hi @RobertD I'm very happy to discuss further. From what I can tell, from your description of GoalPost, you are most likely correct. If I'm not wrong, with GoalPost, you are building a service that is hosted on a server whereas Kendraio is building an app that is installed on the end-user's local device (mobile/laptop). However, if you present all functionality as APIs then Kendraio App can provide the end-user with a view on to your service via an UI that they control. Kendraio is being build to provide the end-user with more freedom. Freedom to choose and modify their own UI and freedom to choose how they combine and visualise the data that they interact with from all the service providers that they interact with. This is very much about decoupling the user interface and user experience from the hosted services and data. And also reducing data siloing where user data is captured within each service. I hope that makes sense. So, actually Kendraio is a great fit with any hosted service that has a decent API. We are collaborating in multiple sectors and with services that have APIs in order to demonstrate how this app could be a personal hub. So, I reckon GoalPost would most likely be a great fit. Cheers!

@Daniel Harris Would love to learn more about how readily the Kendraio app could be applied to provide users more freedom in crafting their own experiences and sharing spaces while accessing our services that in turn access open protocols and APIs. Like Kendraio, we intend to ensure our services are lightweight enough that they can execute in and on local user devices as well as community servers. Care for user privacy, anonymity and local control of knowledge sharing, are all critical features we plan to be support in our services. Look forward to the discussion next week and seeing if there are deeper ways we can collaborate.

For my part I'm adamant that what's needed is a modular system defined by protocols. The offers and wants is clearly the most important functionality. I see it as a web service with 3 discreet components:
- storage with detailed filtering.
- indexing the global filtering via murmurations
- some kind of AI to help with matchmaking
- some design patterns and code for the UI

@Matthew Slater All on-board with the needs you identified, Matthew. We are leveraging a multi-layer, modular service architecture, with each driven by a defined open protocol and open source components. Based on resource constraints, we are prototyping each layer incrementally. This definitely includes AI for matchmaking, as you can see in my response to Oli in this thread. I look forward to a deeper discussion!

The other day a fediverse enabled marketplace was brought to my attention. This Italian community implements the open source "flohmarket" software: http://FediMercatino.it People can publish their offers (and wants I suppose). The platform is ActivityPub enabled so people with accoubts on other fefiverse instanxes can just as well communicate with the people publishing their ads. It is still quite simple, but possibly a good start. This bei g inside the fediverse makes it potentially very powerful.

Probably @Lynn Foster and others have heard of this already, but I thought it useful to share. Also thinking of Bonfire having this functionality in their roadmap. What do you think of this?

@wouterfreeknowledge.eu thank you, I had not heard of flohmarkt, and am happy to know of them, and will try to learn more. I don't know if they used the FEP (fediverse extension proposal) for offers/wants using Valueflows, but I'm guessing probably not.

I agree about the potential power of getting this kind of work into the fediverse. I'd be interested in exploring how the pub-sub architecture of Murmurations (and therefore PLANET) which supports broad publishing and discovery could be used with the actor model of ActivityPub in the fediverse to support the conversational interaction not really supported with pub-sub. I'm wondering if there could be a relatively seamless use of both for offers/wants (for example), making best use of both architectures?

Hi All,

Quick update: We've been debating the core features for the MVP and, based on the obsevations that making a Groups based system is HARD... and that integratinging chat is problemeatic (since everyone already has too many chat systems / their preferred platform) and technically resource intensive, we've been thinking more about the core requirements of the MVP... and ways to ensure it's attarctive / useful enough to gain users...

I've attached the latest thinking as a PDF - which links to some other User Story Docs (forgive me, these are in G-Docs, if you don't want to enter the Google Death Star to view these let me know and I'll make PDFs so you can comment here and I'll incorporate comments into future iterations).

It would be really useful to get some constructive feedback on this - especially from everyone who voted to say they would be happy to feedback and test ideas... I will kick off a poll too... :)

Hi @Oli SB nice one! I'll take a look over the next 48 hours. Excited to see where your thoughts go. I get the thing about not liking Google Docs but I also feel we should be pragmatic and if there are no open source and free(dom) systems that work well for us I am not afraid to use tools from the dark side 🙂 to do a good job. We use Google Docs extensively because they work well so I'm really happy to comment in those docs if I can. Cheers!

@Daniel Harris cool - my thinking too... you (and anyone with the link!) can comment in all the Docs :)

@Oli SB I have one question about the features describe in the Opportunities section, and the limitation on which parties could publish Offers and which could publish Wants. Is there any reason to limit who could publish either? Per our discussion about GoalPost, when working with small groups and non-transactional collaboration, it’s not only Orgs that publish Wants. Individuals do as well all the time. In particular, we have some situations where they explicitly said they could see themselves reaching out across a trust network for services (offers) to fulfill certain needs (wants). The reverse is true as Orgs may want to share offers that meet the situational wants of certain individuals. I just want to make sure that it’s the intent of the MVP to support all these situations.

@RobertD agreed - sorry if that was not clear / needs updating - Yes, I think both types of members should be able to publish Offers and Wants

@Oli SB Thanks - that helps!

it was me that pointed out that doing groups is HARD, but this was in the context of building a monolithic application and then adding groups later, when you have to extend literally every feature to accommodate groups.
But there is another approach, which is how I'm encouraging CES to be architected, which is to make groups the driving force of the software architecture, as we see mastodon.
- users sign up to one and only one group (which implies place-based groups)
- each group runs a full instance of the software
- the protocols support all the features that need to work between groups.
I would be very happy if PlaNET took this approach although it only supports mutually exclusive groups. If other types of groups are needed, that would still be HARD!

@Matthew Slater When you capitalise HARD does it stand for anything (an acronym) or do you just mean it's very hard? cc @Oli SB

@Daniel Harris when I used caps on 'hard' I just wanted to emphasize it would be very hard!

@Matthew Slater, @Oli SB is there a middle way? My concern is around power structures: implicit and explicit. Much (or all?) of the technology we use creates implicit power structures that are baked into the systems we use but rarely discussed. For example, as soon as we touch any app we lose so much freedom because non-developers cannot alter the structure of the app they are using. And we don't talk about this because we think it is too hard to solve. But what if we could solve these issues?

So, listing the values that you want in the world is as crucial as user requirements before any design topology is defined. Of course, I'll instantly break my own rule and from a gut reaction say: how about a many to many approach? Then the user has freedom to move from one instance to another without asking for permission. The user can then interact with more than one instance if, for any reason, some instances block others. Mastodon is great but also has some very heavy dictatorial aspects that are baked into the architecture. I'm not saying it's wrong. I'm just wondering if we can do better.

Ah! One last thing. Having aspirations which we don't know how to implement today is OK. We can just build to what we do know and then experiment thereafter. We need to be prepared to experiment because if we only build what we know how to build then we wont innovate. Of course there's nuances in everything here but I hope you get my drift.

Another last thing, groups are made up of individuals. Individuals define groups by agreements. Please let the process of forming and agreeing group structures be decoupled from the technology hosting the group system. Again, it's about people being free to decide their own destiny and not be dictated by a select few who just happen to host the system. Can we bake in (more) freedom? What's the goal here?

@Daniel Harris  can you talk more about the restrictions inherent in mastodon And remember that every restriction is a form of simplicity that makes it more buildable, and every option adds complexity. Also remember that users could create different accounts in different groups without any load on the architecture. Only if the same identity is in different groups do architects need to care.

Hi @Matthew Slater sorry I let this one slip for a few days. Yes, I totally get that "every restriction is a form of simplicity that makes it more buildable, and every option adds complexity". To the question about Mastodon, I've noticed in most of the installations the moderators will post a list of blacklisted installations that they do not sync or interact with. That's totally fine for their own policy and yes, it's part of the architecture that they have control over who they sync with. But as a user, I have very little say. As a human being I want control over my life. And I want people and technology to stop telling me how I need to behave or who I can talk to. I'm not calling your position wrong in any way. I understand you are coming from the developer point of view of how to make systems more easy to build and maintain. I'm just coming from a different point of view: that of the end-user. I want more control for the end-user. So I'm not talking about what is beautiful for the developer, I'm talking about what is beautiful for the end-user, and of course they seem not necessarily aligned. Which is fine. That's why I talk about project values. Because once we know what the project values are, then we can discuss more details. And not all projects have to have the same values in order to integrate and collaborate. Kendraio can connect to anything with an API whether they are pro developer or pro end-user, if you get what I mean.

@Matthew Slater good Q: I think it's best if we answer for ourselves, and our Orgs, in real life now...

@Oli SB I just tried to vote and have a question. Did you intend for the only possible answers to be 1 or 5? Because those are the only answers the poll is letting me enter.

@Jennifer Damashek you can slide the sliders to any number from 1 - 5... maybe this is not the best type of poll for this but I think it works OK

It is particularly difficult to rate some of these features, especially given the emphasis placed so often on "trust" - a concept that is not defined anywhere here. Whatever realistic meaning it may have, it is highly contextual, conditional, subjective and inconsistent (like another over-used word - "value").

That does NOT mean that I don't see considerable potential value in this project. (NB, my use of the word "value" here is entirely subjective, as I believe it must always be.) I hope that in due course my own modest projects (which focus on areas neglected by others) will be able to interact with this (among many others) to contribute to an increasingly synergetic ecosystem.

In my experience of developing digital products, it's more effective to develop the problem statement we're trying to solve with this product. The features are then decided to support the realisation of the impact. I feel somewhat in agreement with @John Waters. It is difficult to rate 'features' because I am not clear on what the product's true north is.

I'm having trouble with the poll, and I think I have figured out why. I would participate in PLANET minimally out of solidarity with the people and effort, like adding my organizations. But I don't think I would actually see it as something to actively use, I have enough choices already that have chances to be more broadly interoperable, so it would probably be all 1's for me.

The problem comes down to not seeing why to start another architectural ecosystem from scratch at this moment in history. For some time, I've casually thought about Murmurations and the Fediverse/ActivityPub as parallel efforts, and focused on trying to understand what each is best for architecturally, and figuring out how to use them both in projects. I've been in an "all open progressive experiments are good" mode.

What I've just come to is that I don't actually think it is a good idea to proliferate underlying architectures with many overlapping functional features right now, unless there is an important technical or governance reason to do so. I of course could be wrong, and I'm not a technical architect, and I do see some use cases where the Murmurations architecture makes a lot of sense, like the map of organizations. But I don't see an important reason for the way I understand PLANET. I do see lots of reasons to support the Fediverse and make it better, because it is actually the thing that is out there, is growing, and is challenging the corporate social platforms. And I like the decentralized federated model for many reasons, including scalability and that it encourages flexible governance and cultures of groups. The Fediverse certainly has growing pains, and ActivityPub certainly can be improved as a protocol, but also it can carry any objects, so there is lots of flexibility for extending with more features. And there are other technical ecosystems that I don't know much about too, Solid, Nostr, etc., but the Fediverse seems to have the most grassroots momentum atm.

I expect y'all thought about this already, and I'd be interested in why you decided not to go Fediverse. Or disagreements on why not to have multiple protocols around for these eventually broad sets of interconnected use cases. Thanks!

Hi @Lynn Foster. I used to think similarly about non-proliferation of open-protocols. We all remember the cartoon. But I now see open-protocols just like I see APIs and services. There's loads of overlap and in some cases lots of good old fashioned competition. And I don't see a way to stop every new generation coming along and reinventing the wheel just because they want their own badge on it. By the way, that's not what I think is going on with Murmurations. It's just how humans are. Let's not fight it. Let encourage it. This is my personal way of thinking. Because we are never going to get everyone to align behind one API or open-protocol – or even just a few of them. That doesn't mean we shouldn't try to make great APIs or awesome open-protocols. It just means we should allow for many of them.

This is part of my not-so-recent human philosophical insight: I want, above all else, to be with the "what is"; to not fight against the "what is". Sure that doesn't mean we can't strive to make things much, much better. But just... Oh, you know the Serenity Prayer! ;-)

The reason why we hate the idea of multiple protocols is because our whole app paradigm is skewed to one app for each protocol. Our apps/interfaces are vertical, immalleable, monoliths. And it's only by chance (maybe even mistake) that I came across a different way of doing things. Personal, locally running apps can be hubs: points of integration for multiple APIs and open-protocols, all under the end-user's control. I understand this won't click for most people because how can they have an understanding for how powerful this idea is when there's pretty much no examples of it out in the wild. And in this new paradigm of no-code, local-first, malleable-interface, augmented-data, unified-addressing, gradual-typing, user-configurable, user-customisable, super-app we don't need to worry about proliferation of open-protocols. We can celebrate what is happening. We can celebrate the "what is". We can have Murmurations sitting along side any other protocols within the end-user app. And it's all under their control. Developers have no say. Services have no say. Governments have no say. I like this world. I like being in control of my own little world.

One thing that I would like to see more from Murmurations (@Oli SB) is a much greater surfacing of networks that are using it. And also (but perhaps this is happening) much more evidence of onboarding new networks. This is not a criticism because I know this is hard work. But spending 50% of project time on outreach and collaborators is really working for us in Kendraio. And I think it would also work well for Murmurations too. Coming into a project and knowing who's involved really helps confidence levels. I see 6 on the homepage. Are there more?

@Daniel Harris thanks for the response!

>Our apps/interfaces are vertical, immalleable, monoliths. And it's only by chance (maybe even mistake) that I came across a different way of doing things. Personal, locally running apps can be hubs: points of integration for multiple APIs and open-protocols, all under the end-user's control.

Yes this is the beautiful contribution of Kendraio, and I think we are all agreed we want to get away from the monoliths.

Do you have thoughts about interops that happens server-to-server instead of client-to-server? (Sorry if that is the wrong terminology for where we are going, maybe backend and frontend instead of server and client?) Does it not matter to you because everything is made interoperable on each client? Or do you think backend interops shouldn't exist?

Really great question @Lynn Foster. Here's my thoughts about interops that happens server-to-server. I don't think backend interops shouldn't exist. From the point of view of me, as an end-user, my guess is that by using a personal local agent/hub/app I personally might not need the services, that I use, to pass around data, about me, between them. I might even ask them politely not to do so. Because I will be able to provide them with all the information I want to, in order for them to fulfil the function that I want them to complete for me. I just feel more empowered even saying that! ;-)

However, of course there's a need for servers to communicate with each other. I'm totally for that. Lots of (maybe micro) services all providing (little) bits of storage and functionality. We've even talked about a version of Kendraio running headless (no UI needed) in the cloud (hosted instances)... maybe. Basically an always on personal (AI optional) agent. By the way I hate the way everyone assumes that personal agent means AI – it doesn't in our world at least.

And I understand the need for shared indexes and shared data and shared understanding. And then there's the whole ID thang. And actually, to give a thumbs up to Mastodon, I do like the way that they've got over the universal personal ID (in a federated world) by just making it domain specific. Domains are not new of course. I like to see the domain (or name space) idea taken further. Where every assertion/fact has a load of meta data attached to it, like: who authored it? Is it a local copy? Where's the original? This is probably getting into semantic web world (groans). But yeah, I'm a secret fan. I just don't think they provided good enough useable apps to get it going well.

We should also all really acquaint ourselves with (yet another) initiative (sorry) to get their take on how they are seeing the new world order (the good version I mean). As far as I can tell the Local-first community is advocating much of the compute power happening on local end-user devices. But what they really need is a bunch of servers/services to provide persistent data storage for any set of people wishing to collaborate in realtime of asynchronously. But it seems they are suggesting these services could be quite generic and be able to cater for a whole host of data types and scenarios.

I don't see any of what I've said as being incompatible with how things are now. I don't think we should need to break things to get to where we want to go. I think any transformation/innovation can/should be gradual. Otherwise there can be a backlash from hardworking people who just want to put food on their table. And luckily, given our collective resources, I don't think we have any option but to take it slow. ;-)

And I really want to be compatible with how things are and I don't want to force anything change though. I want people to change because they think it might be beneficial for their own interests. And then change is more likely to stick.

@Lynn Foster I'm with you on this, that we don't want to reinvent all new architectures. In fact, my understanding was that Planet would embrace and build upon the already existing open protocols, as much as that is sensible. So ActivityPub/Fediverse should be one key part IMHO. But maybe I'm not following in sufficient detail all conversations in here to see if and how I misunderstood.

BTW I'm researching for a study for the municipality of Amsterdam to support community economies (with Sophie Bloemen / Commons Network), and that brought me to study the [beckn protocol](becknprotocol.io). You are probably aware of it, but for those who aren't: this is a universal protocol enabling p2p discovery of offers and wants and transactions between the consumer & the provider. AFAIK it is used in India, Nepal and Brazil for ridesharing apps, energy grids, health care and local trade.

To me it seems to connect very much to ValueFlows and Holochain (and Planet for that purpose!). Is it something you have looked into, any opinion you care to share?

@wouterfreeknowledge.eu thanks for this!

>In fact, my understanding was that Planet would embrace and build upon the already existing open protocols, as much as that is sensible. So ActivityPub/Fediverse should be one key part IMHO.

Can something like PLANET work if it is partly federated and partly publish-subscribe? Maybe it can, but I have not been able to figure out how to cleanly fit those together unless they are supporting pretty separate functions... but again I am not a technical architect.

>BTW I'm researching for a study for the municipality of Amsterdam to support community economies (with Sophie Bloemen / Commons Network)

I'd be very interested in your research. Amsterdam seems to be involved in a lot of positive experiments.

I really think that the tech doesn't exist for any kind of sophisticated decentralised social networking. Looking at ActivityPub and Nostr, one would think that socialn etworking was basically about publishing and following. But when you think about what groups actually do once they get bored of chatting and and memes, those protocols start to look inadequate, and the groups leap onto a range of different apps:
- local governance / voting
- shared document editing
- shared calendars
- kanban
- arranging meeting times
and much more.
As the author of a community currency payments protocol, I can tell you that you can't do payments simply by broadcasting web objects to your followers, and that as soon as you become serious about a function, it needs its own protocol.
So I'm interested in a whole new approach to decentralised social networking in which
- each group has its own instance
- each function has its own protocol.
If PlaNET isn't doing that then in my opinion it isn't breaking any new ground.

@Matthew Slater thanks for this!

>Looking at ActivityPub and Nostr, one would think that socialn etworking was basically about publishing and following. But when you think about what groups actually do once they get bored of chatting and and memes, those protocols start to look inadequate, and the groups leap onto a range of different apps:

Yes totally! But if you dig into ActivityPub, it is basically activities carrying objects. If you put your objects (including complex ones) where the object goes, and use the create update delete activities, I think you can make it work for most things. One exception would be actually effecting a crypto or bank transfer, where there is a whole other security layer involved, and probably there are more exceptions. Maybe there are some security or privacy concerns that need to be layered on to other things too? Don't know. Also I haven't tried coding this, so haven't run into many of those devils in the details I'm sure.

>- each group has its own instance

Yes, groups are weak to non-existent in the fediverse, but people are working on them. And maybe the actor model won't really work very well for groups in the way I would like, i.e. I want to belong to many groups (which have their own instances or not) with my one actor. Don't know, but I think it would with some additions. It might be worth exploring what Bonfire (a new fediverse app) is doing with groups (or group-like things, circles and boundaries last I checked), and also they are actually getting quite close to a 1.0 release candidate after many years of work and re-work.

I just have to wonder if there is a way to do what PLANET wants to do, and be able to connect with the fediverse, which I think of as pretty key in the @Daniel Harris "what is". In this case, it has more users and momentum than anything else I know of that is decentralized and can be more or less distributed, and is a bunch of semi-coordinated grassroots efforts culturally.

I know I'm asking more questions than providing answers, but am happy to help with some detailed architectural research and work as my skill set allows.

@Lynn Foster you're right I'm not aware of the full possibilities of activityPub, so I'm speaking from intuition a bit. I suspect that Bonfire's groups will help a lot, but they've been a long time coming!

Hi Matthew, I can appreciate what you say, and I like the idea to have instances at group level, maybe like in the cooperative group buying world. With my family unit I was once part of a cooperative buying group of 30 families, which we ran as our own "instance". Then again there is also Open Food Network where national communities provide an online platform where buying groups can organise their catalogue and make purchases from the selected providers. Two different models if you want.

In any case, what about the beckn protol, do you or anyone here know of it? It seems like an interesting p2p network that enables peers to transact on a local basis. With networks by sector, mobility, food, ridesharing, health running in some countries. There are different protocols for different functions, as you say, Matthew. And more can be developed. Interesting framework?

@wouterfreeknowledge.eu Beckn looks lovely, but intended specifically for decentralised commerce. Its functions are discovery, order booking, payment, delivery, and fulfilment. As such it would overlap with familiar things like Murmurations and ValueFlows. More study would be required when the time is right. I think integration with OFN would be a good thing too, but what we need to focus on is designing a core application that can plug into all these things...

@wouterfreeknowledge.eu I think I more-or-less agree with Matthew, Beckn looks interesting, but looks pretty specific to e-commerce, especially as currently done, assumes money and the conventional artifacts. Possibly would only handle a subset of offers/wants? Also probably wouldn't handle things like working together on a project? But I didn't get very deep, I could be wrong. Also agree OFN would be good to explore at some point, certainly if we have a food network use case.

Hey everyone,

Quick update on the PLANET research and experimentation:

We've been diving deeper into the O&W app idea and having conversations with various Network Admins—like those at the Global EcoVillage Network and Transition Towns—to gather feedback on whether a hosted, interoperable,O&Ws app is of interest... the latest iteration of the idea is here:
🔗 O&W App Presentation

Meanwhile, @Geoff Turk has been making solid progress on DID Auth as a way to handle authentication using the Web Crypto API. This could be a simple, elegant way to manage Groups and provide authentication across different services. You can check out the work-in-progress here and even try it out if you're curious:
🔗 DID Auth on GitHub

(A blog post explaining what this is and why it's useful is in the works!)

We've also been reading @Grace (Rebecca Rachmany)'s research on Verifiable Communities, which maps directly with @Matthew Slater's thinking that "each group needs its own instance" and "each function needs its own protocol". You can explore Grace's research here:
🔗 Verifiable Communities Overview
🔗 Verifiable Community Specifications Draft

(Some of the use cases might even give you a laugh! 😆)

We really like the rationale behind this approach, and we already have some of the necessary building blocks for this type of system in place:

• The Murmurations Index could serve as a Registry

• DID Auth gives us a foundation for Community Credentials

So now, we're exploring specifying the finer details for a potential MVP/demo for a system that enables truly decentralized Group management with built-in decentralized ID and authentication.

TBC!

Please share any thoughts / feedback :)

Oli

@Oli SB Wonderful progress! Thanks very much for sharing this. @Grace (Rebecca Rachmany) I am so excited to learn about Verifiable Communities and how you are designing it to adapt to the needs of different types of communities and how they all verify community membership in different ways. I think this offers a lot of promise for our Communities of Care and would like to try it out in our next GoalPost prototype. We are already planning to interoperate with Planet via Murmuations. We have unique, robust community authorization requirements for O&W that we can address at the community boundary, but I’m interested in understanding if you had considered addressing authorization and deeper trust considerations at some point within Verifiable Communities.

@RobertD My perspective is that "deeper trust" can only be held in human form, not in digital form. Groups can have their standards of relationship and trust, and individuals can have deep trust. However, it cannot and should not be done in digital form because people withhold information, particularly negative and intimate information. The Verifiable Community is designed as a basic "good standing" credential for gating different types of physical and digital access. Deeper trust is expected to happen within membranes, or within human contact. I would be happy to discuss your use case directly.

Here's the blog post Oli mentioned above about DID (public key) authentication:
https://ic3.software/blog/simple-secure-login-demo

Skip to the demo section if you just want to see what it does:
https://ic3.software/blog/simple-secure-login-demo#demo

Or skip all the way down to the technical details if you want to understand how it works:

https://ic3.software/blog/simple-secure-login-demo#technical-details

All of this is still a work in progress but we're making good headway.

I think that's exactly what's needed, Geoff.
Can you confirm my understanding that:1. Any web service in the ecosystem is tied to one and only one group core service, and every request is authenticated against that service, which constitutes a short delay?

1. If a service wants to support many groups (or groups served by different group cores) then an extra header would be needed to tell the service which group to authenticate against.

@Matthew Slater 

1. Either should be possible; each web service can be tied to one or more groups, as the service operator chooses (groups might find it easier to pool resources and share a service). Regarding authentication, each user-to-service request is authenticated like in the demo app for user-to-group core, and practically speaking there is no delay (just a few milliseconds to verify the signature). Authentication of a user via the group core to the web service will be minimal as well, and only is needed at the first request. The web service just needs to check the user's public key is still on the list of members' keys at the group core.

2. Yes, exactly. We're looking at using UCANs as one possible way to do this, so that the user's roles and permissions for that web service are also included, as determined by the group core.

@Grace (Rebecca Rachmany) We fully agree with you that establishing deep trust between people lies in the world of building and nurturing small, caring and living communities, Just to clarify that what I was trying to say about deeper trust was meant to point out that our communities need robust authorization capabilities, above and beyond authentication. We need this so that both individual community members and communities themselves can retain sovereignty over deciding if/how they want to share their data.

My sense is that the discussion that you, @Matthew Slater and @Geoff Turk have been having is about finding effective ways to authenticate people using a distributed vs. centralized mechanism, and that DiDs might provide that implementation mechanism. The Verifiable Communities seems to allow identity to take place at a community level, which very much fits the way we establish a community identity context in GoalPost. If so, that’s great and we would love to have a direct conversation with you about that. If anyone else would like to attend, they would certainly be welcome 🙂