Feed parsing endpoint

[stakwork]

Feed parsing endpoint

[tomastiminskas]

@CypherPoet I did the 2 changes you suggested. Definitely we should call ITEMS to the feed items in a feed. I just missed that.
@Evanfeenstra please apply those changes

Regarding the Value, Model and Destination:

• Value: not actually needed since it contains the Model and the Destinations array. In kotlin app I skipped that and linked the Model and the Destinations to the Feed object (maybe we can remove it from the response @Evanfeenstra ?)
• Model: the type is usually lightning and the suggested value is an amount in BTC to send to the destinations. We were using it at the beginning before we built the slider to set the sats per minute to contribute. But good to have that information.
• Destination: type is usually node, the address is the public key to send the sats to, and the split is a percentage of the suggested amount to send to that destination. For example there might be 2 destinations, each one with 50 on split (which means half of the amount set as contribution will be sent to each destination)

[tomastiminskas]

One thing to consider is that not all feeds has a unique ID, so we should define some logic to build a unique ID for each feed. I would say id should be a STRING and it could be build with something like:

• SOURCE_ID (if id exists)
• SOURCE_LINK (if id doesn't exist)

But not sure about this.

[Evanfeenstra]

ya, many of these fields will be empty. For example Medium posts look like they just have id, title, link, and description. In fact, i dont even see "author" on medium channels or posts. Any thoughts?

[tomastiminskas]

yeah, that's correct. Some of them will be empty depending on the source. I added all the needed fields. Author could be empty for medium newsletter, but filled for substack newsletters or items.

We need to define a logic to build the IDs as I mentioned on a comment above, since most of the content (but the podcast index items) have no id, and we need one for each feed and feed item.

[CypherPoet]

One suggestion here: I would change the episodes property on the top-level feed structure to items. This would be consistent with the fact that we're calling the individual entity an Item, and also with the standard RSS key name of item.

[CypherPoet]

It also might not hurt to have contentType as a part of Item. That would allow for the possibility of some feed's items potentially having different contentTypes.

[CypherPoet]

Furthermore, some documentation on what Value, Model, and Destination represent would also be helpful, as right now, I can't really discern what these represent based upon the description above.

[tomastiminskas]

@CypherPoet Just as a note FeedDestination should have a composited primary key of feed_id and address. Otherwise we can run on the duplicated destinations issue (since new destinations with same address will be inserted for the same feed every time data is fetched) which would cause multiple pmts going out to same destination while listening to a podcast or sending a boost.

[Evanfeenstra]

It also might not hurt to have contentType as a part of Item. That would allow for the possibility of some feed's items potentially having different contentTypes.

there is "enclosureType" on each item

[Evanfeenstra]

The endpoint on the test tribe server supports all the above RSS sources. for example https://tribes-test.sphinx.chat/feed?url=https://bitcointv.com/feeds/videos.xml?videoChannelId=2