Make included gardens more visible

[bmann]

Making the gardens included more visible, and also making it so people can file an issue / PR a new garden in order to be included.

[flancian]

Nice! Yes, that makes sense. I think it can go hand in hand with yaml support perhaps?

• There is an agora.yaml in each agora (root repo) detailing what is in it
• There is an agora.yaml in each garden that says how the garden should/could be integrated to an agora.

Then adding a garden is sending a PR requesting adding a line to the agora.yaml hosted in an agora repo; and running an agora yourself becomes just bringing up an agora with a local yaml. The garden yaml perhaps results in a singleton agora.

Wdyt?

[bmann]

So the user instructions would be something like:

To have your digital garden added to the agora, make an agora.YAML file in the root according to this example file (LINK).

File an issue with the link to your Git repo that contains your garden Markdown files.

For developers, You may also make a PR adding the link to this agora.YAML that closes the issue.

Please join us in MATRIX-ROOM (link) if you have questions.

---

The aggregation file should maybe be called gardenlist or similar. Seems confusing with two files named the same.

[flancian]

SG, it will probably be gardens.yaml (the convention I'm testing in the [[agora]] proper is that plurals tend to be lists by default).

Will take a stab at this soon, hopefully [[2021-03-21]].

[flancian]

I've been thinking about this and I'd like to go with this design: https://anagora.org/agora-bridge

Essentially [[agora]] (the core git repo) would contain a bridges.yaml, which serves to configure [[agora bridge]], which is a distinct repo with code and instructions useful for people to run any combination of bridges supported by it. It can be used to "feed" an agora, but I think it could also be used to configure arbitrary integrations. If you set up ingestion for digital gardens, any [[agora yaml]] therein is used to set up the [[agora]] for the user.

https://anagora.org/agora-design for the high level repo story (three repos in total).

[bmann]

I think the architecture is totally up to you. I was highlighting how I think the user interface should work from the user point of view.

If I understand this correctly, the bridge repo has a gardenslist file? And for an agora instance you direct people to this other bridge repo to include their garden?

[flancian]

The bridges.yaml file (which replaces the previously mentioned gardens.yaml in this setup, but could also be called that) would in this case go in the [[agora]] repository, as the gardens included depend on the agora; the agora is a contract plus pointers. But the .yaml would be picked up by code developed in [[agora bridge]], yes; and a particular bridge would take care of running the pull loop to get data from git to the right agora directory.

Illustrative YAML follows:

---
- user: flancian
  input:
    format: git
    url: https://github.com/flancian/garden.git
  output:
    format: agora
    uri: agora/garden/flancian
- user: bmann
  input:
    format: git
    url: https://github.com/bmann/bmcgarden.git
  output:
    format: agora
    uri: agora/garden/bmann

[flancian]

The advantage of doing it like this is that we could relatively easily use the same format to configure a variety of bridges; for example [[moa]]. That would look like a user with [[moa]] input probably, and an [[agora]] or [[git]] output, plus optional configuration to filter and define where posts should be written.

[flancian]

Oh, I did this and forgot to close this :)

I think before closing I'll make the instructions more visible, though. I think by adding a /login link up top that directs to login+onboarding.

[flancian]

Finally got to do this :)

https://github.com/flancian/agora-server/commit/5868e4a0536ff9cab5ae7d92f972af699bef9f7d

https://twitter.com/flancian/status/1483900807557029888 for more examples.

Thank you for your FR! Your contribution makes the Agora better.