Jose Celano

> I think we need to revisit if we actually need the tracker API to have the `api/v1/torrents` endpoint. > > In the last meeting we decided that we didn't...

Hi @WarmBeer thank you for the summary. I have a question: doesn't the `BoxCar` solution always increase the amount of memory consumed? Shouldn't we remove the "removed" torrents from time...

> > Hi @WarmBeer thank you for the summary. I have a question: doesn't the `BoxCar` solution always increase the amount of memory consumed? Shouldn't we remove the "removed" torrents...

Hi @WarmBeer. I think, in the end, the `BoxCar` vector is like a database table but in memory with all the announced torrents. Maybe the core tracker should have its...

> @josecelano @WarmBeer The box-car vector contains only a small amount of data per entry. > > `BoxCar` > > This is memory efficient. > > Yes is it is...

Hi @WarmBeer It's not clear to me what you want to achieve. I guess you want to get rid of the secondary data structure `PersistedTorrents` keeping the "empty" torrent entry...

Hi @WarmBeer, thank you! I think this is a better solution because: - I think we should not have duplicates in the BoxCar. - This solution also has a memory...

Hi @WarmBeer, > Hi @josecelano , > > > > Currently no API endpoint needs write access to the torrent repository as far as I'm aware. But even if we...

Hi @ngthhu, Each option has its pros and cons. > If we don't want unregistered users to see the images, should we handle it on the API side instead of...

> I apologize for the delayed response. No worries. > > > the users can just copy/paste the original URL and load it if they want. > > So we...