So we should upload attachments from the client to the blob directly and also send information to the backup service separately, also from the client, what attachment belongs where?

That's right. Worth noting the backup service isn't the only holder for an upload blob.

Here's how I imagine it going:

1. User uploads attachment to the blob service
   • I forget how we make sure there is a holder at the start, but I remember we discussed this
   • I think we either assign a temporary holder, or we have a rule that we don't delete a zero-holder blob until some time has passed since it was uploaded
2. User sends the attachment as part of a message
   • This goes to Tunnelbroker, and so Tunnelbroker attachs a holder to the attachment
   • Either we have one holder for each recipient, or just one total holder
   • Tunnelbroker clears its holder(s) once all messages have been delivered to the recipient
3. Next, both the sender and recipients now have this attachment as part of their backup
   • Each user (sender and recipients) send a log to the backup service referencing this attachment
   • The backup service attaches a separate log for each user

I think we can do this without the tunnelbroker layer for now. I think that injecting it later in the tunnelbroker's going to be relatively easy.

Yes I agree! I was just listing everything for context, hoping that seeing the whole thing is helpful

I'm basically copy-pasting my feedback from last time

Not sure why, honestly. You don't have to keep linking your answer in every following message - I saw it.

Not sure about those lines... I don't have context on what they do.

What context? The entire context is that we store the attachment holders assigned to specific backup/log items. Not much more to say about these two lines. It's pretty simple as I linked just fields of database "entities".

And if we store these holders, then we need to provide them somehow to the backup service.

Each user (sender and recipients) send a log to the backup service referencing this attachment

This is exactly what I'm doing here. How else do you imagine performing at this point? We just have to update items in the database with specific attachment holders, so certain logs have attachment holders assigned accordingly.

I really don't understand what's wrong here for you, this change is really simple but if you feel like blocking this for another day, then fine - let's talk about this in 1v1.

Sorry about my comments above – I failed to actually read the changes in the most recent update to this diff, and I didn't do a good job of reading through @karol-bisztyga's previous comments.

This diff is actually doing something necessary – part 3 of my long comment above.

It's ok, thx for the review.