github-starred/cobalt
2
0
Fork 0
mirror of https://github.com/imputnet/cobalt.git synced 2026-05-21 14:00:26 -05:00
Code Issues 1.9k Packages Projects Releases Wiki Activity

Provide optional extracted data in the API response #552

New Issue
Closed
opened 2025-11-09 09:52:20 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-09 09:52:20 -06:00
Owner
Copy Link

Originally created by @m-ehsan on GitHub (Nov 9, 2024).

describe the feature you'd like to see

Is it appropriate to provide some extra service-specific data related to the media that has been extracted in the API response? Data items like tweet text, Instagram post caption and ...

In my opinion those kind of data are still public and are tightly related to the media file that the user has requested. In addition they are already accessible in the fetched data. Having an optional field in the API response can satisfy needs of more users.

I suggest adding the field below to tunnel, redirect & picker response types:

key type values
misc object optional extra data related to the requested media

And of course this misc field would be service-dependent and dynamic, leaving room for future changes in the returned items. Also there will be no assurance for it to contain the same set of items every time, it may even contain no items at all. It just should return any relevant item that is possible.

example value of misc field for Instagram service:

{
    "caption_text": "..."
}

Other accessible fields that might be relevant: comment_count, like_count, play_count, taken_at

What do you think? Is this a reasonable feature for this project?

additional context

No response

Originally created by @m-ehsan on GitHub (Nov 9, 2024). ### describe the feature you'd like to see Is it appropriate to provide some extra service-specific data related to the media that has been extracted in the API response? Data items like **tweet text**, Instagram post **caption** and ... In my opinion those kind of data are still public and are tightly related to the media file that the user has requested. In addition they are already accessible in the fetched data. Having an optional field in the API response can satisfy needs of more users. I suggest adding the field below to `tunnel`, `redirect` & `picker` response types: | key | type | values | |:-------------|:---------|:------------------------------------------------------------| | `misc` | `object` | **optional** extra data related to the requested media | And of course this `misc` field would be service-dependent and dynamic, leaving room for future changes in the returned items. Also there will be no assurance for it to contain the same set of items every time, it may even contain no items at all. It just should return any relevant item that is possible. example value of `misc` field for Instagram service: ``` { "caption_text": "..." } ``` Other accessible fields that might be relevant: `comment_count`, `like_count`, `play_count`, `taken_at` What do you think? Is this a reasonable feature for this project? ### additional context _No response_
GiteaMirror added the feature request label 2025-11-09 09:52:20 -06:00
GiteaMirror commented 2025-11-09 09:52:21 -06:00
Author
Owner
Copy Link

@wukko commented on GitHub (Nov 9, 2024):

cobalt is not some kind of api wrapper, it’s a downloader

plus, this info is useless unless you use the api for scraping

@wukko commented on GitHub (Nov 9, 2024): cobalt is not some kind of api wrapper, it’s a downloader plus, this info is useless unless you use the api for scraping
GiteaMirror commented 2025-11-09 09:52:21 -06:00
Author
Owner
Copy Link

@dumbmoron commented on GitHub (Nov 9, 2024):

from CONTRIBUTING.md:

adding features or support for services

... the cobalt api is built to assist people only with downloading freely accessible content. other functionality, such as:
...

  • scraping unrelated information & exposing it outside of file metadata

will not be reviewed or merged.

cobalt is a media downloader tool, not a webscraping tool, so this is wholly out of scope

@dumbmoron commented on GitHub (Nov 9, 2024): from CONTRIBUTING.md: > ## adding features or support for services > ... the cobalt api is built to assist people **only with downloading freely accessible content**. other functionality, such as: > ... > - scraping unrelated information & exposing it outside of file metadata > > will not be reviewed or merged. cobalt is a media downloader tool, not a webscraping tool, so this is wholly out of scope
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
3rd party app support
bug
can reproduce
can't reproduce
documentation
duplicate
feature request
help wanted
instance hosting help
invalid
main instance issue
need more info
needs fixing
next major
not an issue
pull-request
Mirrored from GitHub Pull Request
 question
region lock issue
security
service request
skill issue
web ui
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/cobalt#552
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?