Feat/cache integration

[tobi-bams]

Cache integration added to relay

[Evanfeenstra]

Cool @tobi-bams !

I don't see how the test can work, if you don't add "preview" to the tribe.

Next, we need a separate route to set the "preview" field in a tribe. The main relay config can have a default_cache_host or the route can accept a host as well.

The preview field should just be the host and port of the cache server, so in getCacheMsg you need to add "https://" to the beginning like: https://${preview}/api...

[tobi-bams]

Cool @tobi-bams !

I don't see how the test can work, if you don't add "preview" to the tribe.

Next, we need a separate route to set the "preview" field in a tribe. The main relay config can have a default_cache_host or the route can accept a host as well.

The preview field should just be the host and port of the cache server, so in getCacheMsg you need to add "https://" to the beginning like: https://${preview}/api...

@Evanfeenstra, I was able to do some manipulation on my local machine to add the preview to the tribe and the test did pass.

I will also create the route that stores the preview, My concern so far is how do we tend to validate the preview URL to ensure the URL is valid(that is a valid cache server)?

[Evanfeenstra]

@Evanfeenstra, I was able to do some manipulation on my local machine to add the preview to the tribe and the test did pass.

I will also create the route that stores the preview, My concern so far is how do we tend to validate the preview URL to ensure the URL is valid(that is a valid cache server)?

Good point. When you add the preview, you should hit the endpoint to check it works. You can GET /pubkeys from the cache server, which will return the "pubkey" and the "contact_key", which then you can use the add cache server to the tribe as a member. Make sense?

[tobi-bams]

@Evanfeenstra, I was able to do some manipulation on my local machine to add the preview to the tribe and the test did pass.
I will also create the route that stores the preview, My concern so far is how do we tend to validate the preview URL to ensure the URL is valid(that is a valid cache server)?

Good point. When you add the preview, you should hit the endpoint to check it works. You can GET /pubkeys from the cache server, which will return the "pubkey" and the "contact_key", which then you can use the add cache server to the tribe as a member. Make sense?

Yes, it makes sense!!!

[Evanfeenstra]

@tobi-bams I removed the DEFAULT_CACHE_HOST for now, i want to make sure it works 100% before merging anything that could make existing tribes miss messages

The last step is to add preview to the tribes server when updating from relay. The route is PUT /tribepreview/{UUID}?preview={PREVIEW}

[tobi-bams]

@tobi-bams I removed the DEFAULT_CACHE_HOST for now, i want to make sure it works 100% before merging anything that could make existing tribes miss messages

The last step is to add preview to the tribes server when updating from relay. The route is PUT /tribepreview/{UUID}?preview={PREVIEW}

Alright...

[Evanfeenstra]

@tobi-bams

• tribe owner should always save all the messages

• also we need to avoid saving messages in other routes like receiveBoost, receiveAttachment

[Evanfeenstra]

Great. Tomorrow can you try all the tribe tests with preview set to make sure nothing breaks

[tobi-bams]

@Evanfeenstra fields that are not present in cache object

[
  'created_at',
  'updated_at',
  'receiver',
  'remote_message_content',
  'subscription_id',
  'seen',
  'tenant',
  'person',
  'forwarded_sats',
  'push',
  'only_owner'
]

[Evanfeenstra]

last thing @omoniyi24

add cache field here. https://github.com/stakwork/sphinx-relay/blob/master/src/tests/config.ts

If that is set then the tribe tests run setTribePreview with that value. That way we can flip it on and off later