Use post-as to post to external twtxt.txt files via picoblog's API
In relations to my pixelblog project i have this idea to be able to use yarn as interface to post to picoblogs API:
I imagine that we can use the post-as option, where you add the API-endpoint and -key to a new section under yarns settings.
This way I can reply as
@sorenpeter (darch.dk/twtxt.txt) and not just
@darch on twtxt.net
Is this something that can be done? (Seem like you missed this in all the other chatter/yarning today:)
Sorry @sorenpeter I didn't get to this one 😅
What you are really tlaking about here is "Cross Posting"
I think this is what you want.
If so, does anyone else desire to ahve this as a feature on their Pods?
If there's enough interest in this, I'll reopen a nrew issue describing this as "Cross Posting" and reference this issue.
I believe what @sorenpeter is asking is two way synchronisation, but I might be wrong. If not, then it goes beyond the scope of Yarn.
If he's asking for a two-way thing, then yeah No. Just like we won't integrate with the so-called "Fediverse" either. As much as it pains me, "integration" is a rather hard thing to get right two-way. The problem I often isee is:
- Other platform/service is proprietary so you can't integrate at all.
- other platform/service uses some insanely complciated protocol (e.g: Mastodon / ActivityPub)
I am however trying to work with micro.Blog to get micro.Blog users into Yarn/Twtxt -- Still a WIP though...
I'm not sure if you can call what i'm asking for is Cross Posting or two way synchronisation...
The feature I would like to see in yarnd is that when you press post after you have selected a specific Post-as from the dropdown, the messages is not written to a twtxt.txt file on the yarn-pod, but is send to an API on another server like darch.dk/twtxt/api (no a valid endtpoint atm) and then it takes care of writing to darch.dk/twtxt.txt
Right now i follow my own feed darch.dk/twtxt.txt on my twtxt.net account, and instead of build a seperate full blown client, I want to use the powers of yarn, like threading/forking etc. to be able to have a dialog with people replying to darch.dk/twtxt.net
@sorenpeter Having given this a lot of though... This is what we're going to do:
- Add support for two-way Syncing of a feed.
- Add an API
/api/v1/syncto support this
- Add a
yarnc synccommand to support this
Once that's built you will be able to achieve your desired outcome by regularly syncing the two feeds. i.e: You would create a new Persona/Feed on your @email@example.com account (doesn't matter what it's called) and then you would regularly sync it with your other
twtxt.txt feed hosted elsewhere with a simple Cron job and some shell scripting.
This was a planned feature anyway, I just need to go write it, but first I'll document and write the Issue/story around it.
Still not sure that is what I'm after, so more "hmmm...."
I'm not look for sync between servers, just a basic POST from yarnd to the pico API. Did you read any of the links in OP about the picoblog API just so we are talking about the same thing?
I want to be able to post from my own php interface and edit the twtxt.txt manually and the also use yarnd as a front-end to post replies to get the hashes and correct links for mentions. Uploading media is not a requemnet, since I'm building my own interface for that. So I just want to use a yarn pod to read others feeds and occcationally reply as darch.dk/twtxt.txt instead of twtxt.net/u/darch
And I don't want to rely on cron jobs and other shell scripting to pull the twtxt.txt file to my own server from a pod for several reasons: I want something that does not requeres SSH access to the server, because you need to pay more for that on most hosting providers. My vision is to have something plug-and-play (or upload and play), so only php-files. Also I don't get why the data needs to be on the pod also, when there is an API that it can just post it to.
I imageing the addition to yarnd to be very basic, but I'm just dreaming stuff up here:)
@sorenpeter I get what you're asking for...
But understand that this feature request (at least the way I see it) is a rather "special" use-case.
What's why I'm trying to see if you can't do the same thing with a more "generalized" approach.
Let's keep this issue open, and give us some time to work on some other needed things that overlap here and see what we can achieve?
And no what you're asking for isn't as simple as you might think :D There are a lot of security considerations fow how you invision this to be working ;)
Deleting a branch is permanent. It CANNOT be undone. Continue?