Newer/Unanswered Questions

Older Questions

• Are we currently using the interlay git repo/graph on the current agora?
  • It’s my understanding that the agora is using gardens.yaml to build the agora. I feel like we need to make a decision on that before we can programatically add repos to the agora
  • Yes, we’re not currently using git submodules or subtrees; we’re still just using https://github.com/flancian/agora-bridge/blob/main/pull.py which clones each repo in a target dir.
    • We could move to git submodules, but I’m not sure it is blocking?
    • Yeah I guess it’s not blocking we can just put in the current "garden" path into the config file and I’ll leave out any sort of magic for now
      • totally, yeah — ‘target’ in the yaml should actually be relative to the agora root, it’s an easy fix to make that I can do independently in pull.py. feel free to assume target works like this :)
    • E.g. [[agora bridge]] could just write a file like gardens.py ‘mounting’ each of the git repositories it’s serving so pull.py can then pull them in — that way it seems like we can keep the complexity of ‘mounting’ all in pull.py
• Q: could you use [[go/agora-bridge]] repo (the one in github) to do development? maybe in a branch? I know it’s a bit of a hassle as you started in -js but I think it’s better if we use the same repo for now. wdyt?
  • Sure I just had the existing repo with the code, but we can move this to python if you want. See the stoa is useful. We weren’t even working in the same language lol.
  • No, I mean, I think JS is the right language for this :) It’s just that I think we should stick with one repo for all agora bridging :) wdyt?

Agora Bridge

• Hello my friend!
• [[push]] [[hedgedoc]]
  • [[meta]] We should make [[wikilinks]] work :)
  • I actually really like how it supports a reasonable featureset out of the box, like images:
  • 

    ⥅ [[https://doc.anagora.org/uploads/upload_c0f8839ace0a4b1a732fefacb0b928d9.png]]

• Now about actual [[agora bridge]]:
  • api to add repo to agora
    • /repo/add (takes json?)
  • api to push content to agora using managed repos
    • /push/node? (takes arbitrary resource?) if we push content via http how is this a benefit over just using an [[agora client]]
  • this is more generic, lets anyone say ‘please add this URL or resource to this Agora at a certain place’ — it is resource-granularity instead of user granularity essentially
  • in a way it would feel more like people using the stoa: they need only care about a (resource, node) pair, no need to become agora users?
  • also this way people don’t need to learn git :) interesting. i wonder if we should have a writable ui like we were working on so people can edit managed repo from the site

I’m on mobile so my formatting is shite lol

• haha, I was wondering! that makes complete sense :)
• I think yes, we need more write paths to the agora. the nice thing about this is that we keep clients super simple: an agora client becomes anything that 1. writes to a repo and tells us about it or 2. asks us to take something and put it in a repo for them. the second is more of a nice to have than strictly needed; if everyone was running things like promnesia, we wouldn’t need this :) but IMHO this will make it more 1. diverse and 2. hackable
  • also I totally need this so agora bot doesn’t need to deal with git repos. it seems like it’ll be great to be able to ‘just curl to an agora nearby’ and get git repo management done by a server
  • i like this idea a lot
  • then again perhaps I’m old school and always thinking of the server side :) unsure. what’s old is new again :)
  • [[meta]] also honestly I’m digging hedgedoc, this coloring thing actually kind of works? it’d be nice to have ‘different colors for different users’ as an option though, perhaps that’s doable yeah I’m liking it a lot actually
• (I probably have to go take a walk/deal with some packages, will be back later)
• do you think /repo/add and /push/node make sense? if not in name/path, in essence? i would use /repo with POST verb then we can use same url for GET oh, that makes sense, yes. I did a few REST APIs once upon a time but I sort of became a fan of ‘anything goes’ Agora style :) I think you’re right though I would recommend same with /node so /push takes a post which is a json payload with node=x and body=y?

no /node takes a PUT that updates or creates SGTM :)

rest is for managing resources

• about gardens.yaml: I think I’ll rename it. or perhaps I already have :) need to check. in any case, I want to make it so that target: takes a path relative to the agora root. this way we can really map git repos to any agora path and have the agora mount them, essentially turning the agora into a layered filesystem.

i like this idea

let met check if I’ve already done the first part — i want to do this and also add hedgedoc as stoa before leaving for vacation :) but if not I’ll do it on some free moment in Italy, even though the plan is to disconnect as much as possible to fight against burnout :) do you think you will be able to give the api a shot? no pressure of course.

yeah that’s why i wanted this doc lol

:D

also, when you said rest is for managing resources, do you mean that it applies here well or doesn’t? I think you meant the earlier.

wait, hedgedoc is coloring the left hand side with user information! the line by the number

i meant it applies well because we are doing literal resource management. create/read/update/delete of nodes and repos

yes, I like that a lot. and then the pitch is: if you have CURL and are fine with a REST API, you can write to an agora without auth

later on we might want to solve hard things like file storage in special repos and such :) there’s a git plugin/extension that is meant for large/binary file management, I forget the name

git lfs large file storage

indeed :) I wonder if there’s lfs in ipfs? :)

I’m not sure why ipfs would need it. large files are a failing of git internals

no, I mean the other way around — like, store large files on ipfs. unsure if it makes sense though.

oh you mean use ipfs for lfs storage. that might be a thing already

yeah, true.

[[aside]] perhaps [[radicle]] is something close to this

radicle sounds familiar i need to check it out again

:)

Newer/Unanswered Questions

Older Questions

• Are we currently using the interlay git repo/graph on the current agora?
  • It’s my understanding that the agora is using gardens.yaml to build the agora. I feel like we need to make a decision on that before we can programatically add repos to the agora
  • Yes, we’re not currently using git submodules or subtrees; we’re still just using https://github.com/flancian/agora-bridge/blob/main/pull.py which clones each repo in a target dir.
    • We could move to git submodules, but I’m not sure it is blocking?
    • Yeah I guess it’s not blocking we can just put in the current "garden" path into the config file and I’ll leave out any sort of magic for now
      • totally, yeah — ‘target’ in the yaml should actually be relative to the agora root, it’s an easy fix to make that I can do independently in pull.py. feel free to assume target works like this :)
    • E.g. [[agora bridge]] could just write a file like gardens.py ‘mounting’ each of the git repositories it’s serving so pull.py can then pull them in — that way it seems like we can keep the complexity of ‘mounting’ all in pull.py
• Q: could you use [[go/agora-bridge]] repo (the one in github) to do development? maybe in a branch? I know it’s a bit of a hassle as you started in -js but I think it’s better if we use the same repo for now. wdyt?
  • Sure I just had the existing repo with the code, but we can move this to python if you want. See the stoa is useful. We weren’t even working in the same language lol.
  • No, I mean, I think JS is the right language for this :) It’s just that I think we should stick with one repo for all agora bridging :) wdyt?

Agora Bridge

• Hello my friend!
• [[push]] [[hedgedoc]]
  • [[meta]] We should make [[wikilinks]] work :)
  • I actually really like how it supports a reasonable featureset out of the box, like images:
  • 

    ⥅ [[https://doc.anagora.org/uploads/upload_c0f8839ace0a4b1a732fefacb0b928d9.png]]

• Now about actual [[agora bridge]]:
  • api to add repo to agora
    • /repo/add (takes json?)
  • api to push content to agora using managed repos
    • /push/node? (takes arbitrary resource?) if we push content via http how is this a benefit over just using an [[agora client]]
  • this is more generic, lets anyone say ‘please add this URL or resource to this Agora at a certain place’ — it is resource-granularity instead of user granularity essentially
  • in a way it would feel more like people using the stoa: they need only care about a (resource, node) pair, no need to become agora users?
  • also this way people don’t need to learn git :) interesting. i wonder if we should have a writable ui like we were working on so people can edit managed repo from the site

I’m on mobile so my formatting is shite lol

• haha, I was wondering! that makes complete sense :)
• I think yes, we need more write paths to the agora. the nice thing about this is that we keep clients super simple: an agora client becomes anything that 1. writes to a repo and tells us about it or 2. asks us to take something and put it in a repo for them. the second is more of a nice to have than strictly needed; if everyone was running things like promnesia, we wouldn’t need this :) but IMHO this will make it more 1. diverse and 2. hackable
  • also I totally need this so agora bot doesn’t need to deal with git repos. it seems like it’ll be great to be able to ‘just curl to an agora nearby’ and get git repo management done by a server
  • i like this idea a lot
  • then again perhaps I’m old school and always thinking of the server side :) unsure. what’s old is new again :)
  • [[meta]] also honestly I’m digging hedgedoc, this coloring thing actually kind of works? it’d be nice to have ‘different colors for different users’ as an option though, perhaps that’s doable yeah I’m liking it a lot actually
• (I probably have to go take a walk/deal with some packages, will be back later)
• do you think /repo/add and /push/node make sense? if not in name/path, in essence? i would use /repo with POST verb then we can use same url for GET oh, that makes sense, yes. I did a few REST APIs once upon a time but I sort of became a fan of ‘anything goes’ Agora style :) I think you’re right though I would recommend same with /node so /push takes a post which is a json payload with node=x and body=y?

no /node takes a PUT that updates or creates SGTM :)

rest is for managing resources

• about gardens.yaml: I think I’ll rename it. or perhaps I already have :) need to check. in any case, I want to make it so that target: takes a path relative to the agora root. this way we can really map git repos to any agora path and have the agora mount them, essentially turning the agora into a layered filesystem.

i like this idea

let met check if I’ve already done the first part — i want to do this and also add hedgedoc as stoa before leaving for vacation :) but if not I’ll do it on some free moment in Italy, even though the plan is to disconnect as much as possible to fight against burnout :) do you think you will be able to give the api a shot? no pressure of course.

yeah that’s why i wanted this doc lol

:D

also, when you said rest is for managing resources, do you mean that it applies here well or doesn’t? I think you meant the earlier.

wait, hedgedoc is coloring the left hand side with user information! the line by the number

i meant it applies well because we are doing literal resource management. create/read/update/delete of nodes and repos

yes, I like that a lot. and then the pitch is: if you have CURL and are fine with a REST API, you can write to an agora without auth

later on we might want to solve hard things like file storage in special repos and such :) there’s a git plugin/extension that is meant for large/binary file management, I forget the name

git lfs large file storage

indeed :) I wonder if there’s lfs in ipfs? :)

I’m not sure why ipfs would need it. large files are a failing of git internals

no, I mean the other way around — like, store large files on ipfs. unsure if it makes sense though.

oh you mean use ipfs for lfs storage. that might be a thing already

yeah, true.

[[aside]] perhaps [[radicle]] is something close to this

radicle sounds familiar i need to check it out again

:)

Agora Bridge

• A [[service]] run by the [[flancia collective]].
  • [[git]] https://github.com/flancian/agora-bridge
    • [[go]] [[git]]
  • Provides [[write]] functions into [[an agora]].
    • It ingests content into the Agora from different sources: [[git]], [[fedwiki]], [[mastodon]], [[twitter]] as of [[2022-09-25]].
  • An [[integration hub]] that hosts [[bots]], [[clients]] and [[bridges]].
    • [[siphons]] of [[public utility]].
  • It tries to assist its users first and foremost; optionally it allows any [[agora]] to interact with [[social networks]], the [[fediverse]] and the internet at large — always as is the intent of its users.
  • Bridges are configured with [[yaml]].
    • The main configuration file for the service is [[bridges yaml]]; it can be passed to the service as a parameter.
    • Bridges can be of type [[input]], [[output]] or [[bidirectional]] (r/w/rw).
      • The default [[input]] bridge is git.
      • The default [[output]] bridge is to a filesystem as per [[git pull]].
    • A per user [[agora yaml]] can be volunteered — as part of a [[digital garden]] if the user participates in an [[agora]] community). This file serves to configure an agora for the user. [[agora actions]] may then take place, including on demand rendering through [[agora server]] and running of [[agora actions]].
      • Signing up to an [[agora]] involves pointing an [[agora bridge]], run by you or by a community, to your configuration file as published somewhere on the internet.
    • Please join us in our matrix room if you have any questions.
    • For developers, feel free to send a PR adding your garden! Or reach out in our development room.
• [[contains]]
  • [[agora]]
    • [[agora bot]]
  • [[moa]]
    • [[twitter]]
    • [[mastodon]]

[[done]]

• Got open source approval process.
• Experimented with [[toot cli]].
• Create [[Mastodon]] account for prod.
  • [[mastodon]] @agora@botsin.space
• set up api for @an_agora on [[twitter]].

[[doing]]

[[do]]

• [[]]
• implement [[agora yaml]]
• implement [[bridges yaml]]
• [[push]] [[agora bot]]
  • Create [[Twitter]] account for testing.
  • Create [[Mastodon]] account for testing.

• working on pull.go
• {{embed [[go build]]}}

Newer/Unanswered Questions

Older Questions

• Are we currently using the interlay git repo/graph on the current agora?
  • It’s my understanding that the agora is using gardens.yaml to build the agora. I feel like we need to make a decision on that before we can programatically add repos to the agora
  • Yes, we’re not currently using git submodules or subtrees; we’re still just using https://github.com/flancian/agora-bridge/blob/main/pull.py which clones each repo in a target dir.
    • We could move to git submodules, but I’m not sure it is blocking?
    • Yeah I guess it’s not blocking we can just put in the current "garden" path into the config file and I’ll leave out any sort of magic for now
      • totally, yeah — ‘target’ in the yaml should actually be relative to the agora root, it’s an easy fix to make that I can do independently in pull.py. feel free to assume target works like this :)
    • E.g. [[agora bridge]] could just write a file like gardens.py ‘mounting’ each of the git repositories it’s serving so pull.py can then pull them in — that way it seems like we can keep the complexity of ‘mounting’ all in pull.py
• Q: could you use [[go/agora-bridge]] repo (the one in github) to do development? maybe in a branch? I know it’s a bit of a hassle as you started in -js but I think it’s better if we use the same repo for now. wdyt?
  • Sure I just had the existing repo with the code, but we can move this to python if you want. See the stoa is useful. We weren’t even working in the same language lol.
  • No, I mean, I think JS is the right language for this :) It’s just that I think we should stick with one repo for all agora bridging :) wdyt?

Agora Bridge

• Hello my friend!
• [[push]] [[hedgedoc]]
  • [[meta]] We should make [[wikilinks]] work :)
  • I actually really like how it supports a reasonable featureset out of the box, like images:
  • 

    ⥅ [[https://doc.anagora.org/uploads/upload_c0f8839ace0a4b1a732fefacb0b928d9.png]]

• Now about actual [[agora bridge]]:
  • api to add repo to agora
    • /repo/add (takes json?)
  • api to push content to agora using managed repos
    • /push/node? (takes arbitrary resource?) if we push content via http how is this a benefit over just using an [[agora client]]
  • this is more generic, lets anyone say ‘please add this URL or resource to this Agora at a certain place’ — it is resource-granularity instead of user granularity essentially
  • in a way it would feel more like people using the stoa: they need only care about a (resource, node) pair, no need to become agora users?
  • also this way people don’t need to learn git :) interesting. i wonder if we should have a writable ui like we were working on so people can edit managed repo from the site

I’m on mobile so my formatting is shite lol

• haha, I was wondering! that makes complete sense :)
• I think yes, we need more write paths to the agora. the nice thing about this is that we keep clients super simple: an agora client becomes anything that 1. writes to a repo and tells us about it or 2. asks us to take something and put it in a repo for them. the second is more of a nice to have than strictly needed; if everyone was running things like promnesia, we wouldn’t need this :) but IMHO this will make it more 1. diverse and 2. hackable
  • also I totally need this so agora bot doesn’t need to deal with git repos. it seems like it’ll be great to be able to ‘just curl to an agora nearby’ and get git repo management done by a server
  • i like this idea a lot
  • then again perhaps I’m old school and always thinking of the server side :) unsure. what’s old is new again :)
  • [[meta]] also honestly I’m digging hedgedoc, this coloring thing actually kind of works? it’d be nice to have ‘different colors for different users’ as an option though, perhaps that’s doable yeah I’m liking it a lot actually
• (I probably have to go take a walk/deal with some packages, will be back later)
• do you think /repo/add and /push/node make sense? if not in name/path, in essence? i would use /repo with POST verb then we can use same url for GET oh, that makes sense, yes. I did a few REST APIs once upon a time but I sort of became a fan of ‘anything goes’ Agora style :) I think you’re right though I would recommend same with /node so /push takes a post which is a json payload with node=x and body=y?

no /node takes a PUT that updates or creates SGTM :)

rest is for managing resources

• about gardens.yaml: I think I’ll rename it. or perhaps I already have :) need to check. in any case, I want to make it so that target: takes a path relative to the agora root. this way we can really map git repos to any agora path and have the agora mount them, essentially turning the agora into a layered filesystem.

i like this idea

let met check if I’ve already done the first part — i want to do this and also add hedgedoc as stoa before leaving for vacation :) but if not I’ll do it on some free moment in Italy, even though the plan is to disconnect as much as possible to fight against burnout :) do you think you will be able to give the api a shot? no pressure of course.

yeah that’s why i wanted this doc lol

:D

also, when you said rest is for managing resources, do you mean that it applies here well or doesn’t? I think you meant the earlier.

wait, hedgedoc is coloring the left hand side with user information! the line by the number

i meant it applies well because we are doing literal resource management. create/read/update/delete of nodes and repos

yes, I like that a lot. and then the pitch is: if you have CURL and are fine with a REST API, you can write to an agora without auth

later on we might want to solve hard things like file storage in special repos and such :) there’s a git plugin/extension that is meant for large/binary file management, I forget the name

git lfs large file storage

indeed :) I wonder if there’s lfs in ipfs? :)

I’m not sure why ipfs would need it. large files are a failing of git internals

no, I mean the other way around — like, store large files on ipfs. unsure if it makes sense though.

oh you mean use ipfs for lfs storage. that might be a thing already

yeah, true.

[[aside]] perhaps [[radicle]] is something close to this

radicle sounds familiar i need to check it out again

:)

[https://github.com/flancian/agora-bridge github]

Newer/Unanswered Questions

Older Questions

• Are we currently using the interlay git repo/graph on the current agora?
  • It’s my understanding that the agora is using gardens.yaml to build the agora. I feel like we need to make a decision on that before we can programatically add repos to the agora
  • Yes, we’re not currently using git submodules or subtrees; we’re still just using https://github.com/flancian/agora-bridge/blob/main/pull.py which clones each repo in a target dir.
    • We could move to git submodules, but I’m not sure it is blocking?
    • Yeah I guess it’s not blocking we can just put in the current "garden" path into the config file and I’ll leave out any sort of magic for now
      • totally, yeah — ‘target’ in the yaml should actually be relative to the agora root, it’s an easy fix to make that I can do independently in pull.py. feel free to assume target works like this :)
    • E.g. [[agora bridge]] could just write a file like gardens.py ‘mounting’ each of the git repositories it’s serving so pull.py can then pull them in — that way it seems like we can keep the complexity of ‘mounting’ all in pull.py
• Q: could you use [[go/agora-bridge]] repo (the one in github) to do development? maybe in a branch? I know it’s a bit of a hassle as you started in -js but I think it’s better if we use the same repo for now. wdyt?
  • Sure I just had the existing repo with the code, but we can move this to python if you want. See the stoa is useful. We weren’t even working in the same language lol.
  • No, I mean, I think JS is the right language for this :) It’s just that I think we should stick with one repo for all agora bridging :) wdyt?

Agora Bridge

• Hello my friend!
• [[push]] [[hedgedoc]]
  • [[meta]] We should make [[wikilinks]] work :)
  • I actually really like how it supports a reasonable featureset out of the box, like images:
  • 

    ⥅ [[https://doc.anagora.org/uploads/upload_c0f8839ace0a4b1a732fefacb0b928d9.png]]

• Now about actual [[agora bridge]]:
  • api to add repo to agora
    • /repo/add (takes json?)
  • api to push content to agora using managed repos
    • /push/node? (takes arbitrary resource?) if we push content via http how is this a benefit over just using an [[agora client]]
  • this is more generic, lets anyone say ‘please add this URL or resource to this Agora at a certain place’ — it is resource-granularity instead of user granularity essentially
  • in a way it would feel more like people using the stoa: they need only care about a (resource, node) pair, no need to become agora users?
  • also this way people don’t need to learn git :) interesting. i wonder if we should have a writable ui like we were working on so people can edit managed repo from the site

I’m on mobile so my formatting is shite lol

• haha, I was wondering! that makes complete sense :)
• I think yes, we need more write paths to the agora. the nice thing about this is that we keep clients super simple: an agora client becomes anything that 1. writes to a repo and tells us about it or 2. asks us to take something and put it in a repo for them. the second is more of a nice to have than strictly needed; if everyone was running things like promnesia, we wouldn’t need this :) but IMHO this will make it more 1. diverse and 2. hackable
  • also I totally need this so agora bot doesn’t need to deal with git repos. it seems like it’ll be great to be able to ‘just curl to an agora nearby’ and get git repo management done by a server
  • i like this idea a lot
  • then again perhaps I’m old school and always thinking of the server side :) unsure. what’s old is new again :)
  • [[meta]] also honestly I’m digging hedgedoc, this coloring thing actually kind of works? it’d be nice to have ‘different colors for different users’ as an option though, perhaps that’s doable yeah I’m liking it a lot actually
• (I probably have to go take a walk/deal with some packages, will be back later)
• do you think /repo/add and /push/node make sense? if not in name/path, in essence? i would use /repo with POST verb then we can use same url for GET oh, that makes sense, yes. I did a few REST APIs once upon a time but I sort of became a fan of ‘anything goes’ Agora style :) I think you’re right though I would recommend same with /node so /push takes a post which is a json payload with node=x and body=y?

no /node takes a PUT that updates or creates SGTM :)

rest is for managing resources

• about gardens.yaml: I think I’ll rename it. or perhaps I already have :) need to check. in any case, I want to make it so that target: takes a path relative to the agora root. this way we can really map git repos to any agora path and have the agora mount them, essentially turning the agora into a layered filesystem.

i like this idea

let met check if I’ve already done the first part — i want to do this and also add hedgedoc as stoa before leaving for vacation :) but if not I’ll do it on some free moment in Italy, even though the plan is to disconnect as much as possible to fight against burnout :) do you think you will be able to give the api a shot? no pressure of course.

yeah that’s why i wanted this doc lol

:D

also, when you said rest is for managing resources, do you mean that it applies here well or doesn’t? I think you meant the earlier.

wait, hedgedoc is coloring the left hand side with user information! the line by the number

i meant it applies well because we are doing literal resource management. create/read/update/delete of nodes and repos

yes, I like that a lot. and then the pitch is: if you have CURL and are fine with a REST API, you can write to an agora without auth

later on we might want to solve hard things like file storage in special repos and such :) there’s a git plugin/extension that is meant for large/binary file management, I forget the name

git lfs large file storage

indeed :) I wonder if there’s lfs in ipfs? :)

I’m not sure why ipfs would need it. large files are a failing of git internals

no, I mean the other way around — like, store large files on ipfs. unsure if it makes sense though.

oh you mean use ipfs for lfs storage. that might be a thing already

yeah, true.

[[aside]] perhaps [[radicle]] is something close to this

radicle sounds familiar i need to check it out again

:)

• [[flancian]] https://social.coop/@flancian/107707535126023954 pull
• [[flancian]] https://social.coop/@flancian/108261381970849564 pull
• [[flancian]] https://social.coop/@flancian/108261383011821261 pull
• [[flancian]] https://social.coop/@flancian/108828937591917317 pull
• [[flancian]] https://social.coop/@flancian/109020151020938108 pull
• [[flancian]] https://social.coop/@flancian/109020249248433400 pull

• [[flancian@social.coop]] https://social.coop/@flancian/115476946637283285 pull

• [[flancian]] https://twitter.com/flancian/status/1469757639945240577 pull
• [[flancian]] https://twitter.com/flancian/status/1425106275663290373 pull
• [[flancian]] https://twitter.com/flancian/status/1421566367875190791 pull
• [[flancian]] https://twitter.com/flancian/status/1520808756354994178 pull
• [[flancian]] https://twitter.com/flancian/status/1524303408659845122 pull
• [[flancian]] https://twitter.com/flancian/status/1571531434245988353 pull
• [[flancian]] https://twitter.com/flancian/status/1571524074538516482 pull
• [[2022-10-21 15:09:39+00:00]] @[[flancian]]: https://twitter.com/flancian/status/1583475611275644929 pull

• [[flancian]] https://twitter.com/flancian/status/1472617646067752975 pull

• [[2022-07-09 18:19:39]] [[@flancian:matrix.org]] (link):
  • writes should happen directly from the client, talking to the API, which is part of [[agora bridge]]
• [[2022-07-09 18:24:13]] [[@flancian:matrix.org]] (link):
  • [[agora bridge]] is where the copyright infringement may happen
• [[2022-08-20 16:32:21]] [[@flancian:matrix.org]] (link):
  • I’m going to finally bring up the [[flask api]] for [[agora bridge]]
• [[2022-08-20 16:32:24]] [[@flancian:matrix.org]] (link):
  • and [[agora bridge]] gets [[sqlite]]
• [[2022-09-24 23:08:19]] [[@flancian:matrix.org]] (link):
  • as I need to see if it makes sense to integrate [[moa]] and [[agora bridge]]
• [[2023-07-28 19:08:05]] [[@flancian:matrix.org]] (link):
  • ahoy! [[agora server]] and [[agora bridge]] are both mostly python (with some typescript thrown in), but the idea behind the Agora design is that integrations should be doable relatively independently of these codebases.
• [[2023-07-28 19:19:59]] [[@flancian:matrix.org]] (link):
  • the TLDR for simple one-way syncing (meaning the garden -> agora direction, no agora -> garden updates): you write self-contained code in any language that dumps stuff to disk locally from a remote source, you got an [[agora bridge]].
• [[2024-08-12 11:56:43]] [[@flancian:matrix.org]] (link):
  • Oh yeah, I’ve been dealing with facets while writing the Agora Bluesky bot! Available know at [[agora bridge]]. I’m into that [[pfrazee]] has been doing, there’s some notes from an old meeting with him at his node IIUC.
• [[2024-08-12 17:30:48]] [[@flancian:matrix.org]] (link):
  • [[agora server]] and [[agora bridge]] are 95% Python 😄

• [[2022-03-12 17:35:57]] [[@flancian:matrix.org]] (link):
  • oh, nice! [[agora bridge]] could do this, then just embed the html as a subnode.
• [[2022-04-10 14:00:21]] [[@flancian:matrix.org]] (link):
  • ahoy! yeah, so I went through the internal process to retain copyright on the Agora as a side project and I didn’t get it. so all code (repos [[agora server]], [[agora bridge]]) has Google copyright notices.
• [[2022-04-10 14:01:11]] [[@flancian:matrix.org]] (link):
  • IIUC it doesn’t make a difference as I don’t personally care about copyright. it only affects contributors as they need to sign a [[cla]] (one time only) to contribute to [[agora server]] or [[agora bridge]].
• [[2022-04-13 08:58:57]] [[@flancian:matrix.org]] (link):
  • Oh! Definitely a bug, thanks for reporting. I probably need to work on the [[agora bridge]] codebase, it’s essentially running pretty much the first code I wrote and it doesn’t manage any error conditions very well. Will look into this before work and report back!
• [[2022-04-13 10:58:06]] [[@flancian:matrix.org]] (link):
  • by this I mean: as far as I can tell the only outcome from Google holding copyright for the Agora code ([[agora server]], [[agora bridge]]) is that 1. they choose the license, 2. they choose where the primary repos are to be hosted, 3. they require me to check for a signed [[cla]] before accepting contributions.
• [[2022-04-16 20:21:02]] [[@flancian:matrix.org]] (link):
  • this is now fixed and I’m happier :) this also let me realize I need to handle several more interesting cases in [[agora bridge]]. thank you for the report protopian !
• [[2022-04-30 18:14:42]] [[@flancian:matrix.org]] (link):
  • pull.py git stuff in [[agora bridge]] might be mostly throwaway code then — it’s hacky as it is anyway
• [[2022-05-07 00:21:49]] [[@huggingpuppy:matrix.org]] (link):
  • wondering if https://curius.app [[curius]] can interface with [[agora bridge]]
• [[2022-05-07 00:24:56]] [[@huggingpuppy:matrix.org]] (link):
  • or maybe interfacing [[agora bridge]] with [[hypothesis]] since hypothesis is being used already

• [[2025-11-01 23:06:10+00:00]] @[[flancian@social.coop]] (link):

  • After years of being in the plans, the management interface/API server for [[Agora Bridge]] is apparently happening :D

• [[flancian]] https://twitter.com/flancian/status/1571531434245988353 pull

  • This makes it easier to run and scale, and lets a community-run [[agora bridge]] "takes the heat" when it comes to the complexities of managing personal data (like scaling with the number of connections to platforms, including walled gardens, and optionally circumventing (1/2)- [[flancian]] https://twitter.com/flancian/status/1571524074538516482 pull
  • Then I need to:

• Bring up one new Agora (of [[flancia]], [[shamanic]], [[ogm]]) to test the container setup in https://t.co/BcdFhXFzI2

• Start sqlite experiment in [[agora bridge]], unlocks sign in (maybe I could also use [[moa]] as a base for this though)- [[2022-10-21 15:09:39+00:00]] @[[flancian]]: https://twitter.com/flancian/status/1583475611275644929 pull

Over tcp it serves HTTP: a web interface, [[agora server]].

Port [[5018]] is also optimistically claimed to serve an API, [[agora bridge]].

• [[2025-11-01 23:06:10+00:00]] [[flancian@social.coop]] https://social.coop/@flancian/115476946637283285 pull