FeedDirectory.org as a possible alternative for gpodder.net

Have just put the new code live on feeddirectory.org, along with a short blogpost: Building feeddirectory.org: Permissions, Followers, Comments

I think I’ve covered all of the features that have been requested here and would really appreciate any further feedback. Oh, and yes @ByteHamster, it now supports timestamps. :wink:

Sadly, I don’t own an Android device to enable me to test any AP integration, but will assist where I can with getting things up and running.

3 Likes

Oops, forgot to mention… as part of each API response there’s now a “server-time” component - this is the database transaction time - which should help with any subsequent “modified-since” requests. Use with the caveat I mentioned earlier about updates happening in parallel with the read being invisible.

1 Like

I guess it’s time to create an issue on GitHub for the technical implementation. I’m wondering though, @stucoates, do you plan to make a web interface for people to create & manage accounts?
I can create mock-ups for how that could work in AntennaPod, but I feel that account creation is out of scope (for gpodder.net we also only offer ‘Login’).

1 Like

Hold off doing any design/implementation for a few days. I’ve had a discussion with another app developer about how these things can work and it may be that FD issues unique tokens for an app/user combination - this way a secret reset will not result in the need to re-authenticate everything that’s connected to an account.

For this, yes I will be building a simple account management UI and associated new APIs.

I’ll get back to you once this is done - should be a few days before I’ve made the decision and built the APIs, the UI will probably be done at some point next week.

1 Like

Just for your info, should it be of any help: here’s the log-in process that we’ll soon have for gpodder.net.

Ok, that could be interesting. In terms of user interface, though, I reckon the firs login on a device would still be username-password based (?)

I’m currently leaning towards having tokens that are used by apps to gain access to an account. That way a user can selectively remove the access to apps if they stop using them… it’s also just a single item of data for apps to store and conceals the actual account credentials from apps.

Each account will still have a user-id and secret, but once created, the user will be able to generate (through a web UI or API) tokens for each application they want to give access. The app will just use this token to log in to FD.

I’ll work on streamlined ways to do this for the scenario where a user already has an account and also for new users.

Not sure what’s possible in AP/Android, but if from the app you open a web page, is it possible for the page to send data back to the app by redirecting to a special URL scheme? If so, a token can be handed back from FD to the app without the user having to copy/paste.

I understand the logic, but as a user I would probably create an account on my laptop. If I then would have to log in there and create a token, it’d be annoying to get it to my phone (either store & sync in a txt file or password manager comment, or type by hand).

Instead, if I have a username and password (what you call secret, I think), I could just log in on AntennaPod quickly using the password manager on my phone (which contains the credentials that I created on my laptop). AntennaPod could then submit those credentials to the API and if correct receive and store the token (not storing username/password) - without the user having to think about complicated strings.
Then (as in the new gpodder.net flow linked above) in the next step the user could give the device a name that is then sent to FD (to help recognise the device when managing the account on web).

It exists to open/add feeds, I guess a new scheme would need to be developed/supported for this case.

And one note to set expectations right: I’m happily discussing here with you and would love to see this implemented, but I’m not a developer so it’d be up to others to actually implement it. And whether they want to depends on interest, time, etc.

I think I’ve not explained what I was thinking very well.

Apps will have 2 options to authenticate:

  1. account-uuid/secret combination
  2. app token

For most APIs they are equal. But there will be some small restrictions around what can be done with an app token (e.g. they cannot create new tokens, or list or delete other app tokens… but they can delete themselves).

Apps will be able to create their own app tokens if they authenticate using the account-uuid/secret combination or they can be provided with a token by the user. I suspect we’ll see multiple different ways that app builders actually implement this.

The docs will read:

Applications are encouraged to use an access token rather than the account-uuid and account-secret combination. App access tokens should be placed in the X-FeedDirectory-Client-Auth header, or can be passed as a parameter client-app-token . The use of app tokens will mean that apps are isolated from resets of the main accout credentials - the tokens will continue to be valid. As a general rule, apps should not be storing the account-uuid or account-secret

I’ve done the implementation and hope to release in a couple of days once I’ve done some testing.

1 Like

Should be possible, I think. Firefox, by default, does not open websites with apps that register for a domain but I guess a custom url scheme should work by default.

After a bit longer than I hoped, I’ve deployed a version of feeddirectory.org that implements the app-tokens so that apps do not have to store the account-uuid/secret. The APIs for managing the tokens are:

https://feeddirectory.org/#/api/1.0/App/Token/Create
https://feeddirectory.org/#/api/1.0/App/Token/Delete
https://feeddirectory.org/#/api/1.0/App/Token/All

I will be providing a web UI for managing these also.

Apps do not have to use these tokens for access, but if they do then they will be immune to changes to the account secret, so I recommend that they do.

I hope this is all pretty self-explanatory, but please hit me up with any questions that you may have.

3 Likes

@tonytamsf @Matth78 Would either of you be interested in turning this into a GitHub issue?
@ByteHamster Do you think implementation could benefit from mock-ups, or would/should it look like the new nice gpodder login?

I think we can just re-use parts of the gpodder login screen - so no mock-ups required :slight_smile:

2 Likes

I am about to create an issue for it.
I will keep it simple, so don’t hesitate to tell if what I do need adjustments.
I will edit this post afterward to link to GitHub issue.

Edit :
issue 4986 has been created
After thought, @ByteHamster, I am not technical but with the ongoing effort to restructure / modularize code is it ok to add a syncing service ? Or should some indications / informations be added ?

1 Like

Thanks a lot @Matth78! Maybe it would be good to just add a link to the API specifications of feeddirectory and a note about what it should look like (same as gpodder.net login, as ByteHamster confirmed just above).

Should be okay, I think. The restructuring is done incrementally and I try to not touch code when there are open pull requests in the same file.

Added in issue a link to FeedDirectory.org API, and a note about re-using gpodder login screen with a link to this discussion.

3 Likes

Hi @stucoates what’s the state of FeedDirectory.org? I haven’t heard about it for a while. In the meantime, AntennaPod got support for multiple sync services, so supporting FeedDirectory.org could now be easier than before. Do you still plan to release the source code?

3 Likes

This looks great, thanks for bringing it up, which new sync services were added, and in which version? I was not aware of that!

2.5.0 will add support for Nextcloud sync

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.