diff --git a/sig-support/meetings/035-2024-07-24.md b/sig-support/meetings/035-2024-07-24.md
new file mode 100644
index 00000000..eb319c07
--- /dev/null
+++ b/sig-support/meetings/035-2024-07-24.md
@@ -0,0 +1,209 @@
+# Akash Network - Support Special Interest Group (SIG) - Meeting #35
+
+## Agenda
+- Triaging issues in the support and console repositories.
+- Discuss support feedback from Vanguard insiders and community members.
+- Change in Meeting Cadence
+
+## Meeting Details
+- Date: Wednesday, July 24th, 2024
+- Time: 07:00 AM PT (Pacific Time)
+- [Recording](https://aa2i7ytftmtlehngryvt4m6jnaxvu5ku72e34u5akdetalzdimja.arweave.net/ADSP4mWbJrIdpo4rPjPJaC9adVT-ib5ToFDJMC8jQxI)
+- [Transcript](#transcript)
+
+## Participants
+- Andrey Arapov
+- Damir Simpovic
+- Maxime Beauchamp
+- Rodri R
+- Scott Carruthers
+- Tyler Wright
+
+## Meeting Notes
+**Welcome and Introduction**
+- **Speaker: Tyler Wright**
+- Overview of SIG Support biweekly meetings led by core engineering team members from Overclock Labs, focusing on Akash Network issues.
+- Main topics: Issues in support repo (core product) and console repo (open source console).
+
+**Change in Meeting Cadence**
+- **Speaker: Tyler Wright**
+- Proposal to change meeting frequency from biweekly to monthly.
+- Focus less on issue triaging and more on general support in Discord, Telegram, and other channels.
+- Formation of a new SIG for more engineering-focused discussions.
+- Consensus reached to change meeting frequency to monthly.
+
+**Issue Triage and Discussion**
+- **Speaker: Scott Carruthers**
+- Reviewed open issues by sharing his screen.
+- Identified only two issues awaiting triage.
+
+**Discussion on Inventory Operator Issue**
+- **Speaker: Scott Carruthers**
+- Detailed analysis of an issue related to the inventory operator when pod names exceed 63 characters.
+- Found that while the DNS limitation was acknowledged, the issue did not break the inventory operator in testing.
+- Suggested potential solutions: updating documentation to recommend shorter hostnames or adjusting the pod naming convention to reduce character count.
+- Andrey Arapov questioned whether it was a real bug or just a cosmetic issue, agreeing to verify with the user.
+- Action assigned to Scott Carruthers for further validation and user follow-up.
+
+**Discussion on Exposed Ports Issue**
+- **Speaker: Scott Carruthers**
+- Analysis of a request regarding programmatically querying exposed ports assigned within the container.
+- Maxime Beauchamp clarified the request: customer needs to know the external port assigned to the internal port specified within the container without manual updates.
+- Plan to investigate further with Artur's input.
+
+**Open Discussion on Discord Support**
+- **Speaker: Tyler Wright**
+- Encouraged attendees to drop questions as comments inside respective issues for async discussion.
+- Shout-out to Maxime Beauchamp for handling console-related issues effectively.
+- Mentioned that Discord is the main communication hub for developers using the Akash Network, with additional channels in Telegram and other platforms.
+- Noted Damir Simpovic's work on improving auto-moderation in Discord.
+
+**Announcements and Closing Remarks**
+- **Speaker: Tyler Wright**
+- Reminded attendees of the upcoming SIG Provider monthly meeting.
+- Noted a steering committee meeting happening the next day.
+- Reiterated the change in cadence for SIG Support meetings to monthly.
+- Encouraged continued engagement and feedback through respective issue comments.
+
+## Action Items:
+- **Tyler Wright:**
+  - Announce the change in meeting frequency to monthly.
+  - Provide additional information about the new engineering-focused SIG.
+
+- **Scott Carruthers:**
+  - Review and triage any pending issues in the support and console repos.
+  - Validate the inventory operator issue and follow up with the user.
+  - Show validation steps and respond to the user about the DNS limitation impact.
+  - Investigate the exposed ports issue with Artur and Maxime Beauchamp.
+
+- **All Members:**
+  - Participate in the discussion of open issues.
+  - Monitor Discord, Telegram, and other channels for general support.
+
+# **Transcript**
+
+_This editable transcript was computer generated and might contain errors. People can also change the text after it was created._
+
+Tyler Wright: all right, welcome everybody to six support biweekly on July 24th 2024 Historically during these six support biweekly meetings a group has been led by members of the core engineering team at overclock Labs the core contributors and creators of the Akash Network during the six support biweekly sessions a group has gone over any issues that are awaiting triage in the support repo inside the Akash Network GitHub organization. The support repo is where all issues related to the core product live. There's also another repo for a console where issues related to the open source console live and again usually one if not, Two of those repos and any issues related to the repos are discussed during the six support biweekly.
+
+Tyler Wright: We talked about it recently in the last six support meeting about changing the Cadence of this meeting to
+
+Tyler Wright: A monthly Cadence and just focusing Less on triaging of issues and more on just general support inside of Discord Telegram and other channels the goal is to again do move awaiting issues or waiting triage and have another potentially Sig that gets formed that is more engineering Focus where specific engineering discussions had again, but I think we talked about it last meeting and had a number of folks that agreed following this meeting. We will change the six support Cadence to biweekly me to monthly instead of biweekly and then look out for any additional information on a new Sig forming which will focus on more engineer and core engineering Focus endeavors.
+
+Tyler Wright: But today we will stick with the typical agenda. We will hand it over to Scott to see if there's any issues awaiting triage and then we can discuss any open issues anybody wants to discuss from there. Usually we have members of their cautions either such vanguards here to see…
+
+Scott Carruthers: okay, everyone is able to see the Open issues screen.
+
+Tyler Wright: if there's anything worth talking about as it pertains to support in disorder other channels.
+
+Scott Carruthers: I think there should be pretty quick today.
+
+Tyler Wright: So we'll talk about that. And then…
+
+Scott Carruthers: I think there's only two issues awaiting triage.
+
+Tyler Wright: if anybody has any other items related to support that they want to discuss today we can add those to the agenda.
+
+Scott Carruthers: so let's start with the one on the bottom inventory operator and when I Discovery pod name exceeds 63 character, so I actually did some testing of this. So the reports basically this is the regular DNS label limitation on 63 characters in the issue is when we spawn they inventory operator Discovery pods if this is the beginning of the Pod name We already have already starting with. What rather large amount of characters and then if we were to test and again I tested this myself and as we are expected because it's a DNS. guidance and limitation I was able to reproduce the issue if I
+
+Scott Carruthers: have a kubernetes worker node with that hostname and then it gets prepended by this it will exceed 63 characters and then they inventory operator will Have a log entry state in that. DNS possibly could be affected because of a name over 63 characters the interesting part about this is when I Tested this I think it may be something that we want to consider. So I'm not negating taking a look at But this issue this user reports that when you have a host name that it saves 63 characters that actually broke they inventory operator and that was not my experience. I use this exact same hostname on a worker node ahead. Gpus enabled and the inventory operator was picking up the gpus and of course all the other hardware specs as well.
+
+Scott Carruthers: So I think it is something that we possibly should consider but it's an interesting that so it possibly could have other Downstream effects like I didn't this was just on a test cluster. So. I can't say that there was exhaustive testing done to ensure that this doesn't have any other consequence and again, I think of something that we should look at but in my experience, it did not break the inventory Gathering. So I know that I'm both. Simply Andy are on the call. So you may have some opinions of this yourself. So to me, there's possibly two ways to go with us one would be.
+
+00:05:00
+
+Scott Carruthers: A simple no and our documentation for a Akash kubernetes build that based on the number of characters were already dealing with here that a hostname cannot exceed whatever the remainder of that would be. So that could be a simple step or the other way to go with this and this is what this user suggested is. So this solution would still allow for the possibility of hitting this issue, but it would make it. probably far less likely and that would be an adjustment in our code so that these Inventory Hardware Discovery pods would not be spawned with a name inventory Hardware Discovery, but possibly just instead Hardware discovery. Then of course post-pended by the host name. So if we eliminated the pods whatever that would be like
+
+Scott Carruthers: Maybe possibly somewhere between 15 and 20 characters. We would be getting back to and then this particular host name was. 66 characters. So this example wouldn't have had an issue if we revised the Pod name in so yeah, we could and maybe there's some other suggestions as well. But off the top my head when I was looking at this we could either provide guidance and our documentation and leave or we could encode redo and edit they pod names that are assigned to again, maybe eliminate 15 to 20 characters making the issue far less likely. So, I don't know anything. I think I may have actually heard I'll somebody have there yet. Andy, go ahead.
+
+Andrey Arapov: Yeah. Thanks I was just wondering is there really a bug because it's just the recommendation message a warning letters to me doesn't really pose any real issue doesn't cause an issue.
+
+Scott Carruthers: Yeah, I agree whether it's a bug or just a suggestion and of getting what are the warning like again? If you read through this issue this user is reporting that This was actually causing an issue with the inventory operator. I didn't experience that so we could go back and I could reproduce it and show that the inventory operator and the inventory Discovery is not affected and then Go from there.
+
+Andrey Arapov: Yeah. Yeah.
+
+Scott Carruthers: But yeah to answer your question. the user claims of this introduces a bug, but that was not my experience.
+
+Andrey Arapov: There's nothing like he just described the bug as an inventory operator lock shows. So it just says the lock shows but doesn't mean that it doesn't work or something. It just was looking into the locks. Yeah, it's a good observation indeed just in terms of prioritization that if it doesn't really like you can ask him we can get back to him and ask him does it cause an issue besides that this warning letter if he confirms that it's just the Cosmetics then okay, we can put it as always ferric and then to think about the recommendation updates steps or because otherwise, yeah, we could also optimize the cold. Let's say call it like Opie inventory and instead of Hardware use There are many ways but people can have even longer host names. They can include the main names potentially which is not recommended but anything can be but yeah, we could recommend also those names that's what we actually do. I think in order to presentation I did not explicit.
+
+Andrey Arapov: Say it but in our examples you really have Node 1 or 2 in keep spraying inventory file. so
+
+Scott Carruthers: Yeah. Yeah, okay. Yes. I read through this. It must have been and other communication that this user suggested that the Sasha had an impact on the inventory operator so I can respond to it. I'll sign this to myself initially. I'm so good.
+
+Andrey Arapov: Okay. Thanks.
+
+Scott Carruthers: P2 and I'll just later today show the validations that I went through showing that this didn't seem to have any impact on the inventory operator. So it's basically just a warning and we could get rid of the warning by suggesting shorter post names and see how the user responds. But yeah, I definitely Don't think there's any doubt that this isn't an overly urgent matter any other questions or concerns about this item.
+
+Scott Carruthers: Okay, and then Going back to the other issues that are awaiting triage.
+
+00:10:00
+
+Scott Carruthers: Just leads us one. So this Saturday I was wondering if Max was going to be on this call. I don't. see him on the call so I can definitely reach out to him and ask for further clarification or maybe some others as you read through this might have My provoke some thoughts that I didn't have but if you read through this, so obviously the title is exposed ports assigned within the container. And then Max was suggesting a customer wants to know the external Port assigned to the internal Port specified in within the container. It's currently impossible where the current For the current bit engine so find a way to prove a programmatically query the ports.
+
+Scott Carruthers: I assume that means exposed within the container, but I guess I had an again. I just go to Max and have some conversation about this to make sure that I understand but I wasn't exactly sure what he was requesting. Is this a request that we programmatically display all ports that are exposed within the container or is this talking about? That the user wants the ability to see the associated kubernetes nodeport for report to internal container which that is available. The least status so a user would be able to get that. So obviously in order to create status you would have to have the certificate so it's not. on chain information so I don't if you query
+
+Scott Carruthers: the deployment or you query the lease on chain, I definitely doesn't have that information but it is available and police status. I think I heard a hand ray. So I don't know maybe some others have some thoughts on exactly what they request is here.
+
+Scott Carruthers: You go ahead shampoo.
+
+Scott Carruthers: Yep.
+
+Scott Carruthers: Okay.
+
+Andrey Arapov: For assigned within the content assign using controlled I would even imagine not during the beat but when the container is open running so the application probably from the inside the container could just check and know which parts it's a map to because often you have some kind of minor or some kind of service that needs to know. what external Port it's Maps too. So to tell to the application locally, I remember there was case like this. Could do this.
+
+Scott Carruthers: yeah and after a good time in because Max just joined us so max. We're just going through issues that are awaiting triage and this is The last one in that status so we're just reading through this and I was just trying to ensure that we as a group understand what the request is here. So the node part assigned to a lease or a deployment is not available and on chain information within the appointment or ase. Data that's stored on chain. But of course you can get the assigned kubernetes node Port via lease status, but anybody can do that, but you would need to have this certificate for the deployment to be able to Get that information. So what exactly is the request here? Is it that others besides the person doing the deployment would be able to get the assignment part
+
+Maxime Beauchamp: So yeah, I don't remember. I need to look in this messages which customer exactly but I think it's Venice. Not sure need to look but they wanted to From the get- when creating these no. Which ports are assigned to? the port within the container itself without getting the ports assigned and then updating the deployment through environment variable and stuff. I see. doesn't make
+
+Scott Carruthers: okay, So That's something that they're deployment process would need to know knowledge of the assigned node part for I guess I'm just trying to understand the utility.
+
+Maxime Beauchamp: yeah, so within the container being able to Know which parts? Are being assigned to which part?
+
+00:15:00
+
+Scott Carruthers: Okay, I have it now. So it's basically based on their application needs to have knowledge. What node part was assigned. Yeah, okay.
+
+Maxime Beauchamp: I'll try to find exactly with the details about the requests but From my memory. It was Venice. Not sure.
+
+Scott Carruthers: Okay, so we've had very somewhere requests to be I'm in the past for like some applications needing Knowledge of what they're External IP addresses if they're using IP leases, so now I understand that the issue.
+
+Maxime Beauchamp: Yeah.
+
+Scott Carruthers: I'll speak with artwork and do some further investigation on this but I'll just assign it to myself for All right? Yeah. Thanks.
+
+Maxime Beauchamp: Yeah, sure Arthur. It told me to create the issues. So he's aware of it.
+
+Scott Carruthers: So he's aware of it as Okay, I'll sign both of us and
+
+Scott Carruthers: Yeah that makes more sense. Okay, and with that, I believe that we have now. Tackled all the awaiting Treehouse issues. Are there any other issues on the board that may have been assigned prior on and that anyone wants to discuss further
+
+Scott Carruthers: okay with that. I'll hand it back to you Tyler.
+
+Tyler Wright: Perfect. Thank you very much Scott's. again, if anybody is listening to this later. If you have any questions about any specific issues, feel free to drop that question as a comment inside the respective issue and we could talk about it during the six support call or async with members of the community and Courtney.
+
+Tyler Wright: Cool, just as an aside. We talk about the top of the call, but I always love to shut up Max if anybody has any issues related to console again, you could drop those inside the console repo and they cost Network organization Max B who's on the call here today as well as Max seeing the rest of the team do a great job of responding to any issues and addressing them solving them in a time. They fashion. So again, if anybody has any issues related to console there is an ecosystem console Channel inside Discord as well as the console repo where you can create an issue leave a comment and again get a fast response from Max B or somebody else.
+
+Tyler Wright: cool moving along during this part of the agenda. I usually call upon some insiders to see if there's anything worth discussing in terms of support inside of Discord or any other channels. Again Discord is akash's main communication hub for all developers. There are some other channels and Telegram and elsewhere, but for those that are looking to build on their custom Network for use the accost Network in a technical way again, we try to push those folks to Discord where you can get real time support from members of the community Akash insiders Akash vanguards Etc. But I just want to see if there's anything on the support side or a Discord that might be worth discussing here live.
+
+Tyler Wright: I know that damir has previously seen some hikes in certain terms that are being used and Discord and as an Insider / Vanguard has done a great job of sharing those and making sure that we can improve the Auto mod to kind of block some of those terms. So damir shout out to you rodri. That's the same thing. I just want to see if anything on that front that maybe I haven't seen that needs to be added to restricted words inside of the Akash Network Discord server.
+
+00:20:00
+
+Tyler Wright: excellent
+
+Tyler Wright: excellent Is there anything else on the support front that anybody wants to talk about here today?
+
+Tyler Wright: One thing I will ask is I know that many of these folks on this call are also provider focused. There is a Sig provided monthly meeting that I'll be happening in 38 minutes. There will be some discussion and…
+
+Rodri R: .
+
+Maxime Beauchamp: Thanks.
+
+Scott Carruthers: Thanks.
+
+Tyler Wright: updates from Jigger and Duval and where Prater is and again from the next steps in terms of console. So it'll be some power-up discussion on the provider build improvements led by Scott on this call and just any other provider related discussions. I know there's a group all called SC Prime looking to give a demo at the sick providers monthly meeting in August and there's been doing some behind the scenes work. But again, you all can join that supervised monthly meeting that would be great. And then there's a steering committee happening tomorrow as usual last Thursday of the month.
+
+Tyler Wright: But again look for the six support Cadence to change as we move this back to a monthly meeting. There will be some follow-ups about a new Sig or two that will house the triage process. But again much appreciated everyone's time and efforts today. If you have any comments about any issues again, feel free to drop them in a respective issue Meetings online. Thank you all. Have a good rest of the day.
+
+Meeting ended after 00:21:14 👋