diff --git a/meetings/2023/07/11-telcon/README.md b/meetings/2023/07/11-telcon/README.md
new file mode 100644
index 0000000..ab33f43
--- /dev/null
+++ b/meetings/2023/07/11-telcon/README.md
@@ -0,0 +1,238 @@
+
+
+# Agenda
+
+To add an agenda item, please open _[Biweekly Meeting Agenda Request Issue](https://github.com/patcg-individual-drafts/ipa/issues/new/choose)_ on the IPA Proposal GitHub repo.
+
+Two agenda items:
+
+* [First 45min]  Privacy Budgets in IPA for Ad Networks 
+    * [https://github.com/patcg-individual-drafts/ipa/issues/80#issue-1797341122](https://github.com/patcg-individual-drafts/ipa/issues/80#issue-1797341122) 
+    * [https://github.com/patcg-individual-drafts/ipa/issues/78#issuecomment-1622524556](https://github.com/patcg-individual-drafts/ipa/issues/78#issuecomment-1622524556) 
+* [Last 15min]   Continue discussion on alternative sharding by matchkey designs. 
+    * [https://github.com/patcg-individual-drafts/ipa/issues/75#issuecomment-1629545874](https://github.com/patcg-individual-drafts/ipa/issues/75#issuecomment-1629545874) 
+
+
+## **Attendance**
+
+1. Benjamin Case (Meta)
+2. Charlie Harrison (Google)
+3. Nick Doty (CDT)
+4. Tammy Greasby (Anonym)
+5. Phillipp Schoppmann (Google)
+6. Mariana Raykova (Google)
+7. Christine Runnegar (PING co-chair)
+8. Alex Cone (Google)
+
+
+
+## “Whiteboard”
+
+Questions: 
+
+
+1. What types of queries do different parties currently run? 
+2. Do they really need to run their own queries or is it enough to learn results from other parties?
+3. How can we in IPA’s privacy budget framework support the necessary queries? 
+
+
+### Buy side:
+
+* **Advertisers**
+    * Able to run their own trigger fan-out queries 
+* **Ad Agencies** (advertiser likely use more than one)
+* **Ad Servers**
+    * Considered source of truth .. .like MMP
+    * Make this the central brain for the Advertiser 
+        * Would need extra communication than today. 
+* **Measurement companies** (e.g., MTA vendors, MMPs)
+    * Able to run delegated trigger fan-out 
+    * Q: would an Advertiser ever work with multiple?  
+* **DSPs**
+    * Bid models 
+    * Can share event level outputs for them. 
+* **Trading desk (independent or the agency’s)**
+    * Agency distributes money to trade desks, who work w/ DPSs
+    * Multiple traders for the same Adv but want to do different queries
+        * Can we have a coordinator overall? But not share outputs 
+        * Option 1: each Adv gets budget and gets shared
+        * Option 2: each Trader gets a budget 
+
+
+### Sell side:
+
+* **SSPs**
+* **Ad Networks**
+* **Publishers**
+    * Able to run their own source fan-out queries 
+    * Self-attributing publisher is more like a DSP
+
+
+## Minutes
+
+Scribe: Erik
+
+
+* Ben: 
+    * Hope to collaborate on a table as to the current status of properties of queries.
+    * Do we need to add anyone on the Buy side?
+* Alex
+    * Agency and/or independent trading desk
+    * Takes the money and spends the money on the DSP
+* Tammy
+    * Could we remove the agency then?
+* Alex
+    * Agency still wants to see the data
+    * Traditional role of agency is creative and media, media places budgets.
+    * Sometimes agencies pull levers themselves, or pass it off
+    * Agency is still judged on performance by advertiser
+    * Agency uses advertiser ad server reporting directly, doesn’t rely on trading desk
+    * Trading desks pulls out of DSP
+* Tammy
+    * Lots of programmatic lingo
+    * Trading is the person who places budgets
+* Alex
+    * The person who sets up campaigns, makes sure pixels are there, etc
+    * On a daily basis, go in and see if the campaigns are delivering, if delivering then how they are pacing, and if they are pacing, then they go on to look and see if they are performing.
+* Ben
+    * On behalf of a single advertiser
+    * Do they need different queries, or can they use the same ones?
+* Tammy
+    * Sometimes yes, sometimes no
+    * Advertiser with trading desk in house, yes
+    * Sometimes advertiser will have multiple agencies
+    * Agency can use multiple DSPs
+* Charlie
+    * The way I see this is that the agency and trader are the “entity”, agency potentially stand in for advertisers
+    * Agency wants to see the standard aggregates
+    * DSP needs are to make sure their Bid models are working
+    * If you have some kind of event level privacy mechanism, via post processing you can share out that event to multiple DSPs without using more budget
+        * Maybe a fixed budget for optimization, all DSPs use that.
+        * If it’s event level, they can do their own ad hoc thing
+    * Tricker side is the trader/agency
+        * It would nice to say there’s now a central system, and all agencies look at
+        * That would be a clear separation, but today it’s all colluded
+        * Right now running queries on DSP and advertiser’s ad server
+    * Queries are partitioned by buying strategies
+* Alex
+    * Make sure it’s clear, the budget can be split across multiple entities pulling levers.
+    * Those entities probably shouldn’t be able to see each other’s performance. They don’t today.
+    * Advertiser ad server spits out ad creative code / pixel that gets loaded into the DSPs
+    * Agency and advertiser can see the whole picture if they have it split up, but those who received only a portion of the budget shouldn’t see each other’s stuff
+* Tammy
+    * Easiest way is local DP, and then you can partition beyond that.
+    * Most often, ad server is source of truth.
+    * Empower ad server to send things to DSP, agencies, etc
+    * Would be different from today, but would probably be better
+* Charlie
+    * That seems cleanest to me: make ad server the centralized brain of the privacy budget
+    * Next steps for how this could work:
+        * How do you handle that? 
+        * Who are the traders? 
+        * Who get’s what budgets? 
+        * Is the ad server capable of dropping a file that would specifies this?
+        * Is there a connection between the ad server and the DSP
+* Tammy
+    * Not exactly our problem
+* Charlie and Alex
+    * Need some sort of bridge
+* Charlie
+    * Agree that the way that this life works as a trader:
+        * Login to see if you’re a delivering
+        * Then, and only then, if you’re pacing
+        * Then performance
+        * Then try to adjust the campaign to get better performance
+    * To do all this, their working on non-source-of-truth data, e.g. DSP data. 
+    * There are scraping companies that pull in ad server data to try and join it, etc
+    * In a world where we can get source of truth data, that would be great
+    * DSP is going to ask for event level data, and they want it quick. Their spending is based on things that update more quickly than what we’re talking about.
+    * Assuming a bridge, I just can’t imagine a DSP wanting to be dependent on an advertiser ad server not falling over.
+* Tammy
+    * If we have event level reports, that could go directly to DSP
+    * Only aggregates would not be real time
+* Charlie
+    * If you don’t do the event level thing, the sharing gets more difficult
+    * Label DP is best way we know how to do it
+* Ben
+    * Moving onto sell side
+* Tammy
+    * Publisher use cases
+* Ben
+    * Mostly thinking about publisher optimization
+    * Maybe there needs to be some budget spend on “not across publisher” budget to spend
+* Charlie
+    * Wondering why the publisher needs to do source fanout queries.
+    * Is this acting as the SSP? Or is this self attributing publishers?
+* Ben
+    * Yes, the self attributing publishers.
+* Charlie
+    * I wonder if the place to slot that is more on the DSP side? It’s roughly trying to do the same thing, but for a single publisher instead of lots of publishers.
+    * You could remove source fan outs if you can handle those with the trigger fan outs
+    * Either is a one-to-many or a many-to-many
+* Tammy
+    * One concern is if the advertiser is splitting the budget for open web.
+* Erik
+    * It’s fixed per site
+* Charlie
+    * You have small sites on the display network, it’s unclear what type of queries they’d need to run.
+    * If only the advertiser can run fanout queries, it simplifies things.
+
+Scribe change: Charlie Harrison w/ Phillipp as backup
+
+
+
+* Nick
+    * Catching up a little bit on this issue. Why are we talking about splitting budgets? User doesn’t care. Every reason to think callers will collude i.e. share what they learn. Why would there be a split budget?
+* Erik
+    * You’re on the right track. We need a global budget because we assume everyone is colluding. Budget is 100 unicorns. If there is an advertiser there are different entities that want queries, we need to figure out how that will all work. You can’t give everyone 100.
+* Nick: that’s up to you. Work closely with your partners. Is this coming up in the protocol?
+* Ben Case: Which party? When someone visits a particular site, we bind the report to that site. If there are multiple agencies, do they need to share the budget with that website? We need to think about the potential attack surface.
+    * If the advertiser has a different (independent) budget for each partner, they can amplify privacy loss by creating more partners
+    * We presented two options in PATCG, sharing budget vs. ad networks have their own budget, and system keeps a cap on that
+* Charlie:
+    * Trying to answer the question in a different way. We need to share budget. We need to design a system that is adoptable. Right now, privacy budget is a new thing. The ecosystem wouldn’t know what to do with it. So we need to go through all sorts of use cases to see (1) whether this is feasible at all, and (2) to be able to go to various players and talk about how to use it.
+    * In theory it’s easy to describe how to do privacy budget splitting, but we need to make sure we satisfy all the use cases.
+* Nick:
+    * Why are we talking about different budgets / total budgets (?)
+* Charlie:
+    * We want to match what’s in IPA right now, but we want to figure out how to instantiate it.
+    * IPA has this notion which entities get a fresh budget, and the previous discussion was about whether we need this for all sides.
+* Ben: Can we talk about SSPs?
+* Alex: the category is changing a little bit. Traditionally the SSP probably wouldn’t have a mechanism on the advertiser’s site (a pixel / SDK) to capture a trigger event, even if the publisher wanted it (which they might). They might want to show that they are performing well for the advertiser. But the ability to put their code on advertiser’s site is not there (unlike the self-attributing pub). That’s the canonical case, they don’t have the trigger data. They have click data as a proxy for performance. That being said, the ecosystem is not static. SSPs are starting to approach agencies / buy-side with tools, particularly in areas like CTV. In those cases they might work w/ advertisers to set stuff up. This gets to Charlie’s point: if we consider this conception as the parties that are currently doing attribution, it’s enough. Focus on the buy-side initially.
+* Ben: what about ad networks? Similar category of self attributing publisher
+* Alex: There are multiple types of ad networks, crossing both sides or some skewing more buy-side / sell-side. Variance in terms of how they are doing reporting. A lot of them are white-labeled on the DSP, etc. Someone at the ad network might be one of the parties that the agency hands budget out to, along w/ trading desks. There are people that want to see reports that are at ad networks, but it’s a mix of whether they have a system to pull reports or they pull from someone else.
+* Ben: Source fanout query. We think ad networks need to pull “many to many” queries for optimization. Similar to self-attributing publisher queries.
+* Alex: It’s less clear cut on the ad network side, whether they have their own tech doing optimization. There’s less of that. More so they have their own reporting tech, but some may just be pulling from other systems. Ad networks are more often providing a service on top of other platforms rather than their own tech. There is a slice that does their reporting w/ their own tech, then an even smaller slice doing optimization.
+* Tamara: It might be good to stop thinking about companies, since it’s all nebulous. Publisher-centric algorithms
+    * **Publisher understanding ad load**
+    * **Pricing**
+    * Bunch of buying strategies, auctions w/ floor price. Different deals, commit to buy a certain impression at a certain price, you commit that I will win. SSP might help with this. Today not based on ROAS, negotiated.
+    * Other than SSP direct to advertiser to cut out the DSP / trading desk, I don’t see a reason why they need the data at all.
+* Erik: +1 to that concept. Just getting back to the problems we are trying to solve. Charlie is right we need to figure out how to hoist this on the industry. Two things we are trying to solve
+    * Advertiser wants to understand how ads perform
+    * Publisher who shows ads from bunch of advertisers, want to know how their site performs. Gets passed around to other companies
+    * This is how we came to the two different fanout queries, to answer those questions respectively. It probably wont cleanly map on to existing deployments.
+* Erik: doesn’t the ad network need to understand how valuable the site is? If there isn’t a 3P cookie.
+* Alex: Yes, the point is that they don’t have the implementation today to grab the trigger events. The buy-side has the setup to grab both. You aren’t wrong, the entities in the middle would be looking to do that, the publisher likes it if they are seen as performing well. The question is more about whether the publisher is even set up to grab those events.
+* Erik: Don’t anticipate the publisher setting this up, would assume their display network is receiving trigger events and is optimizing the placement.
+* Alex: they are, but that network is using the tech of the buy-side to do that. Networks are typically companies that provide service on top of their own tech or someone else’s tech, aggregating supply and demand. Buy-side tech is the tech that ends up getting dropped on the advertiser site. Reason that is hard to see on the Meta side is that’s not the case for Meta. You built the tech to do the optimization. Advertisers are used to that with you, but not with the rest of the web. That’s not how the rest of the programmatic web works.
+* Tamara: it is the same at meta. They are optimizing their site because they are working for the advertiser. A side effect is that they can optimize their site. You can let the advertiser control the budget, data can flow to the publisher for whatever optimization they want to do.
+* Ben: it’s interesting to think about. The self-attributing publisher case has the flow in the other direction. Think about a system that can work w/ these different approaches.
+* At time, apologies to Mariana / Phillipp.
+
+Sharding
+
+
+
+* Ben: we like the idea of OPRF matching, trying to think of if theres a way to bound the sensitivity of the match key. Right now we have every time a user visits a particular domain, another copy of the match key in the query. Every time the user clears state, clears it. Other ideas of bounding the sensitivity on the client.
+* Mariana: Bounding the sensitivity, this applies to any type of sharding.
+* Ben: Correct, although more of a concern in the OPRF because the shard size are smaller, you have more of them
+* Phillipp: biggest difference is that some designs will gracefully degrade whereas in the OPRF approach it doesn’t gracefully degrade.
+* Mariana: I’m not sure we know that 100%
+* Ben: Maybe even large shards can be attacked by going above the sensitivity bound, but at least you have some aggregation by that point?
+* Mariana: Main point was this is an issue in any design
+* Ben: We have to make sure we can’t pull budget from different domains
+* Ben: can we avoid pulling reports from other sites
+* Erik: in probabilistic case 
+* Ben: hard to have in context of MKP
+* Erik: brainstorming; care about sensitivity because don’t want to know they are in the intersection. Can we reveal by site and check,  
diff --git a/meetings/2023/09/26-telcon/README.md b/meetings/2023/09/26-telcon/README.md
new file mode 100644
index 0000000..4e73420
--- /dev/null
+++ b/meetings/2023/09/26-telcon/README.md
@@ -0,0 +1,131 @@
+# Agenda
+
+To add an agenda item, please open _[Biweekly Meeting Agenda Request Issue](https://github.com/patcg-individual-drafts/ipa/issues/new/choose)_ on the IPA Proposal GitHub repo.
+
+* We will plan to have a working session with whoever wants to join on the steelmaning the comparison doc from TPAC with a focus on the IPA column.  Particularly there was some feedback to break out the security section into more cases. Links:
+1. original comparison doc [https://docs.google.com/document/d/1oMe3Q7DMG3xzl-peIdq6voVD4PKD822-W4nf4ak7s2E/edit](https://docs.google.com/document/d/1oMe3Q7DMG3xzl-peIdq6voVD4PKD822-W4nf4ak7s2E/edit)
+2. steelman version [https://docs.google.com/document/d/127HgUw8j5G59zOd0PmMZNXmhIETXHPu_Ub0_JIv0YV8/edit](https://docs.google.com/document/d/127HgUw8j5G59zOd0PmMZNXmhIETXHPu_Ub0_JIv0YV8/edit)
+* 
+
+
+## **Attendance**
+
+1. Benjamin Case (Meta)
+2. Erik
+3. Daniel
+4. Phillipp
+5. Mariana
+6. Martin
+7. Alex
+8. Andy
+
+
+## Minutes 	
+
+Scribe: Erik and Ben 
+
+[Note: switching gears to the OPRF topic given attendees]
+
+
+1. Daniel: 
+    1. [sharing a doc, will publish before the next meeting]
+    2. At the start of the MPC, helper parties decrypt events, and check for consistency across helpers.
+2. Erik: event clean up happens in either approach
+3. Daniel: unclear if this is needed in Mariana and Phillipp’s version.
+4. Mariana: There isn’t clean up to do for that version.
+5. Daniel: 
+    3. Then we generate fake events. When we reveal the OPRF of the match key, we reveal how many users there are with 1 event, 2 events, etc.
+6. Mariana:
+    4. Yes, a DP histogram.
+7. Daniel:
+    5. Generate random events for each of these buckets.
+    6. Here it’s crucial that we have an upper bound, otherwise we can’t create fake events for an unbounded number of events.
+    7. We have to values: number of events within a session (easier to bound) and number of sessions per user (hard to estimate)
+    8. If we fail to estimate that, we may result in leakage.
+8. Mariana:
+    9. Assuming we can compute that sensitivity in the MPC with the current approach?
+9. Daniel:
+    10. We don’t leak this histogram in the current approach, so it’s not needed.
+    11. Once we’ve generated the fake events, we need to shuffle.
+    12. After we’ve shuffled, we reveal the OPRF, and then can group by users.
+    13. If there is any group with N<sub>s</sub> * U<sub>s</sub> we can report a privacy violation, but we can’t revert that leakage.
+    14. In order to evaluate the OPRF, we can do something like g^{1/(mk + k)}
+    15. Some details on what is sent…g^r and something times the share…
+10. Mariana: does it take advantage of honest majority?
+11. Daniel: use three party protocol; could do in two party setting, one party for g^r and another g^{r+k}
+12. Mariana: will do proofs or use honest majority to avoid?
+13. Daniel: for multiplication use malicious, proof for same r in g^r and multiplied by shares 
+14. Philipp: Question on privacy violation event. Does it mean one of the servers cheated?
+15. Daniel: Could just be that the heuristic failed. You know how many event you have per session, but not how many sessions per user
+16. Martin: sessions could be capped on device, but if we cap to 100 per device, but a person has many devices then would be more.
+17. Phillipp: cross-device
+18. Martin: even in single device case, then refresh the matchkey.  If same device then we can cap, 
+19. Phillipp: if we could sync matchkeys we can sync session counts.
+20. Martin: yeah, but more chatty 
+21. Daniel: MKP was an issue to bounding events per user
+22. Erik: shuffle step – we want to do OPRF because we want to scale horizontally, need to shuffle in this setting as well. Could cause weakened security.  We can chat more about this in a bit
+23. Mariana: shuffle was a big motivation for our earlier proposal 
+24. Daniel: finishing this doc first.  Do aggregation but still need to sort by timestamp. 
+25. Mariana: doing this per user may not be that bad
+26. Daniel: Some tradeoffs to consider, but yea, events per user will be a smaller set. Not sure if it saves a lot on communication complexity.
+27. Phillipp: Yes, and they can be done in parallel.
+28. Daniel: 
+    16. Then you run aggregation, and that’s simpler as well. Not too different but a little optimized. Boolean shares seem to be better because it’s easier to cap them.
+    17. Biggest bottleneck is shuffling. Currently doing it in honest majority setting, can have two parties pick a permutation, and you iterate that three times so that each party only knows one of the three permutations.
+    18. Issue with this is that you need to keep all events in memory. 
+29. Martin:
+    19. Current bottleneck is on the order of a million events.
+30. Mariana: why need in memory? Not trying to prevent hiding access patterns
+31. Martin: are we leaking through timing?
+32. Mariana: three parties – each party has nothing to hide as they know what shuffle they are applying.
+33. Martin: right, we haven’t experimented with putting on disk, concerned about time
+34. Erik: also nothing leaked by sharding across machines when shuffle is know
+35. Daniel: as long as not doing per shard shuffle
+36. Erik: two stage random assignment
+37. Phillipp: may not get uniform permutation doing it that way
+38. Ben
+39. Mariana: doesn’t get uniform shuffle but done
+40. Martin: If you have two groups, there’s some chance that everything ends up on one shard. Do you need to add noise twice?
+41. Erik: not sure why all on one shard a problem
+42. Martin: 
+43. Erik: three helpers each applying a random shard, then stream out of those, my intuition is you get all permutations, but would need to check
+44. Mariana: goal is to parallelize the shuffling
+45. Eirk: goal of all is horizontal scale, map-reduce style 
+46. Mariana: not sure about uniform shuffle, but not sure you need it either
+47. Erik: suppose 1B events with 1k shards so 1M each.  All helpers know mapping.  Event count to shard. 
+    20. Shuffle each shard
+    21. Same as one query with 1M events, 1k queries with 1M events?
+48. Daniel: depends on DP mechanism to cover imperfect shuffle.  Add fake events inside buckets may not work,
+49. Mariana: eventually doing sharding so we can release PRF values, if you see all the values are on same shard but know where things went before shuffle may violate 
+50. Mariana: goal is to assign to shards based on OPRF value
+51. Erik: would reveal OPRF after we’ve added dummies, then reveal OPRF, might be on different shards at begining but then go to correct shard
+52. Mariana: yes, but not sure the construction will be DP
+53. Daniel: probably not enough to add fake events initially, may need to randomly assign to shards and create more dummy events 
+54. Erik: some HW to figure out 
+55. Mariana: question if is a DP mech, will need to look at new papers that can do without full shuffle. Sent in slack [https://arxiv.org/abs/2305.10867](https://arxiv.org/abs/2305.10867)
+56. Daniel: 
+57. Erik: impact on sensitivity?
+58. Mariana: will have to check. Main different with ours is if you share index or encrypt. Need to encrypt shares anyway so need to rerandomize, shares doesn’t save you so much.  Do distributed evaluation. 
+59. Daniel: we wanted SS to save on PK operations, shuffle of ciphertexts, want to have a non-maliable matchkey so can’t split a user into two so can’t violate per user sensitivity cap.
+60. Mariana: at what stage?
+61. Daniel: if mk with rerandomizable encryption, RC could just add 1 to mk underlying, 
+62. Mariana: but encrypted to helpers with another layer? 
+63. Daniel: probably non-maliable on device and then rerandomizable, but can’t do hybrid encryption with AES, need whole ciphertext with 
+64. Mariana: can’t encrypt shares with AES eithere
+65. Daniel, no but everything SS, no rerandomizing ciphertext. 
+66. Mariana: so maybe this shuffle in MPC is more complicated. 
+67. Daniel: yeah need to be careful to get malicious
+68. Phillipp: shuffle also works on shares 
+69. Daniel: paper that uses set equality check. Different malicious secure shuffles in honest majority, not bad. Can send papers
+70. Daniel: we were concerned about pk encryption and how expensive.
+71. Mariana: protocol not clear without seeing details of shuffle on shares. 
+72. Phillipp: reranomizable large messages, use LWE
+73. Ben: not large messages per user, 
+74. Phillipp: then can use EG
+75. Daniel: 
+76. Mariana: why large message
+77. Daniel: encrypt non-maliable then encrypt
+78. Mariana: i thought other way around
+79. Mariana:
+80. Phillipp: issue of exphiltrating and using over in a different query. 
+81. Daniel: open to other ideas 
diff --git a/meetings/2023/10/10-telcon/README.md b/meetings/2023/10/10-telcon/README.md
new file mode 100644
index 0000000..ca0be9e
--- /dev/null
+++ b/meetings/2023/10/10-telcon/README.md
@@ -0,0 +1,165 @@
+# Agenda
+
+To add an agenda item, please open _[Biweekly Meeting Agenda Request Issue](https://github.com/patcg-individual-drafts/ipa/issues/new/choose)_ on the IPA Proposal GitHub repo.
+
+*  this week in the IPA call Daniel will present more on the OPRF implementation for scaling IPA.  You can read more here [https://github.com/patcg-individual-drafts/ipa/blob/main/3IPA.md](https://github.com/patcg-individual-drafts/ipa/blob/main/3IPA.md)
+
+
+## **Attendance**
+
+1. Benjamin Case (Meta)
+2. Daniel Masny (Meta)
+3. Erik Taubeneck (Meta)
+4. Martin Thomson (Mozilla)
+5. Alex Koshelev (Meta)
+6. Artem Ignatiev (Meta)
+7. Aram Zucker-Scharff (The Washington Post)
+8. Daniel Masny (Meta)
+9. Phillipp Schoppmann (Google)
+10. Miguel Morales
+11. Mariana Raykova (Google)
+12. Andy Leiserson (Mozilla)
+
+
+## Minutes 	
+
+Scribe:  Ben Case
+
+Erik: removing unknow and unresponsive zoom participant “Joo’s OtterPilot”
+
+Daniel: slide based presentation for IPA [PRF-based Approach](https://github.com/patcg-individual-drafts/ipa/blob/main/3IPA.md). New approach to make IPA more scalable.  Some leakage but we can handle with DP. 
+
+We have overall structure worked out which we’ll present
+
+7 steps
+
+* Query format: 
+* Peparaating MPC
+* Fake event integration
+* PRF eval and grouping
+* Per matchkey attribution 
+* Aggregation
+* Release Query Result
+
+Maily will talk about fake event integration and PRF eval
+
+Query format
+
+
+
+* How much DP budget to spend, dp cap, bound of number of events per session and bound on sessions per user.  We can identify at helpers if events generated in same session, could have many. Bound on number of sessions is harder to enforce, could do on device, a bit more heuristic where this could have some drawbacks. But we can control well number of events per session, 
+* Amount of events
+* Event formant
+    * Mathckey which is secret shares arithmetic, others boolean.  Open to suggestions 
+    * Timestamp
+    * Trigger bit
+    * Breakdown key
+
+Prepare MPC
+
+
+
+* Invalide ciphertexts need filtered out
+* Make sure shares are consistent, each helper receives two shares out of three.  Need to make sure share 3 is the same on two of the helpers.
+* Delete events where decryption fails or inconsistent. Could lead to an attack vector from malicious helper to arbitarily delete reports, but we’re not too concerned right now about this
+* Enforce a session bound.  In IPA first secret share and then encrypt.   We cache the secret shares but do fresh encryptions in same session but when you send to helpers they are able to identify these are the same secret shares and detect they are the same session.  So we can enforce bound – delete if there are two many submitted to meet teh bound. 
+
+Fake event generation 
+
+
+
+* DP leakage will need to be covered by fake events.  Generated at this step but needed later.
+* Create fake matchkeys, every pair of helpers generate fake events.  Not clear if we take from the total budget or use other level we are comfortable with. 
+* Create e fake matchkeys with k fake events.  Each pair of helpers generate. Let other helper know how many generated so they can initialize theirs to zero. 
+* Run shuffle protocol. Total amount of events, + fake events.  To hide which are which we run mpc shuffle. We used share based shuffle “Secure graph analysis at scale” paper.   
+    * Each two parties pick and apply permutation in the clear. 
+    * Seems easy to shared as permutation is applied in the clear. 
+
+Sharding
+
+
+
+* Need a perfect shuffle.  Iterate over the list and assign to a random remaining open spot.  Each chosen with prob 1/n
+* Question is how to shard.  Pretty simple, just assign each element to a shard and position within it.  Probability of a shard is proportional to remaining open slots in the shard.  Within the shard run previous algorithm where assign each with 
+
+Phillipp: do we need a hard bound on the number of slots per bound?  Or just an average expected number? 
+
+Erik: i think if you don’t have hard bound you don’t get a uniform shuffle. Don’t prevent the case all appear on only one shard. So 
+
+Phillipp: could have a bound with high probability 
+
+Daniel: if we say each pick uniformly the shard without considering how many remaining open slots, creates a bias. 
+
+Phillipp: in which slot in a shard doesn’t matter. Since shuffle within.  That should be a uniform shuffle if unbounded shard size. 
+
+Erik: ith’s spot goes to p(i)th slot.  Decompose into shard and slot on shard.  First shard is …
+
+Phillipp: still not clear details 
+
+Mariana: do you have analysis, still not obvious to me uniform shuffle
+
+Daniel: yes, can share a proof.  Probabilities multiple and you get s_j to cancel and you get same probability as perfect shuffle
+
+Phillipp: how to communicate number of free slots
+
+Daniel: some load balancer to keep track of where they have been assigned
+
+Martin: should be relatively easy to implement even if not all done ini one place.  Confident works for small numbers would be good to verify. Large number case may not be the same as small.  Doing this in the clear makes easier. 
+
+Daniel: to Mariana’s question on which part
+
+Martin: first one is “fisher-gates” – second one is too if you think of it as two dimensional space,  still drawing number between 1 and i
+
+Daniel: moving on
+
+PRF eval on each matchkey
+
+
+
+* What we have gained is pesudonymn changes between IPA queries.  Could still argue unique per user. Revealing the PRF in the clear need to be careful – can count how many events exist per pseudonym but since we added fake events you only get a noisy version of this information. 
+* Add fake events up to N_s * U_s but if there were a user with more than this bound on number of events. Helpers can detect but once it occurs some information is revealed. Could be hard to enforce on device for usability. 
+
+PRF - DY  (see slide)
+
+
+
+* G is EC generator.  PRF(k,x) = 1/(x+k))*g
+* Generate random r_i, r_{i+1},  move to exponent 
+* Compute shares of z = r(x+k)
+* Reveal R and reconstruct z
+* Haven’t done proof but should be secure in generic group model
+* Reveal R and need to make sure reveals nothing about r
+* Marian: distributed DY, we need to add a random mask in addition to multiplicative mask
+* Phillipp: but on shares probably don’t need
+* Phillipp: paper on how proving in generic group model.
+* Daniel: we get malicious secure if malicious reveal and multiply. Don’t need any zk proof
+
+Per matchkey attribution 
+
+
+
+* Group by each user,
+* Sort in MPC by timestamp
+* Run attribution in MPC – different from previous IPA algorithm for attribution since per user
+* aggregation  – could prun by fixing amount of attributed events per user
+* Release query result. 
+
+Ben: also attribution would also have sensitivity capping so DP noise added is correct amount
+
+Daniel: other questions. 
+
+Phillipp: bottleneck no longer on shuffling? Do you have experiment for this?
+
+Daniel: main complexity is when apply permutation. What is done per element is pretty simple. Main concern was keeping it all in memory.  
+
+Phillipp: and 2 rounds in total.  Happy this seems to work out 
+
+Erik: biggest concern is adding now many events
+
+Erik: depends how sparse and how far you go. 
+
+Ben: each bin needs around 30-40 dummies. Probably 1M or so fixed cost
+
+Daniel: malicious attacks to be prevented on device could have draw back on usability. Enforcing the cap absolutely on device might have drawbacks. 
+
+Daniel:  other topics
diff --git a/meetings/2023/12/12-telcon/README.md b/meetings/2023/12/12-telcon/README.md
new file mode 100644
index 0000000..4d56c94
--- /dev/null
+++ b/meetings/2023/12/12-telcon/README.md
@@ -0,0 +1,105 @@
+# Agenda
+
+To add an agenda item, please open _[Biweekly Meeting Agenda Request Issue](https://github.com/patcg-individual-drafts/ipa/issues/new/choose)_ on the IPA Proposal GitHub repo.
+
+*  this week in the IPA call Daniel will present more on the OPRF implementation for scaling IPA.  You can read more here [https://github.com/patcg-individual-drafts/ipa/blob/main/3IPA.md](https://github.com/patcg-individual-drafts/ipa/blob/main/3IPA.md)
+
+
+## **Attendance**
+
+1. Benjamin Case (Meta)
+2. Daniel Masny (Meta)
+3. Erik Taubeneck (Meta)
+4. Martin Thomson (Mozilla)
+5. Nick Doty
+6. Phillipp Schoppmann
+
+## Minutes 	
+
+Scribe:  Erik Taubeneck
+
+Slides from Ben: [https://docs.google.com/presentation/d/1Gr6pmA6ObyhYTP-Fn5od9DsAcWpP_W1SUKD84MxOXD8/edit#slide=id.p](https://docs.google.com/presentation/d/1Gr6pmA6ObyhYTP-Fn5od9DsAcWpP_W1SUKD84MxOXD8/edit#slide=id.p)
+
+* Ben:
+    * OPRF overview. Don’t get to see individual people, but does reveal # of events per user.
+    * Number of events, T, e.g., [1, …, 100]. For each T, helper parties learn the counts of users.
+    * We can add non-negative DP noise to each of those counts, but adding sets of random events.
+    * Non-negative DP noise provides an (epsilon, delta) guarantee, e.g., there are some extreme cases that may expose an individual’s membership.
+    * Nuance here is that the sum of noise is revealed. This is OK with replacement definition of neighboring datasets for DP, and will cost a factor of 2x in sensitivity.
+* Nick
+    * Helpers would also know how much is added because it’s documented in the protocol
+* Ben
+    * You’ll generate a random amount each time. Each helper will generate ⅓ of the total noise. 
+* Martin
+    * Simplest way to do this to do it pairwise, so each party would know ⅔s the data. Need to add 3 times the noise.
+* Nick
+    * [missed the question]
+* Martin
+    * Want a strong differential privacy argument, then can make some tuning with the epsilons. Here we want to lay the ground work for the fundamentals.
+* Daniel
+    * Two aspects with the ⅔s because we get the malicious security. 
+* Erik
+    * If we didn’t need malicious, it would only be 1.5 more.
+* Martin
+    * Manipulation could get nasty, so we’ll certainly want malicious security.
+* Ben
+    * Need to compose across this histogram. Analogous to the Laplace Mechanism that lets us add (epsilon/Delta delta/Delta)-DP to each component of a vector where Delta = L1 or L2 norm sensitivity, to get (epsilon, delta)-DP
+* Martin
+    * What’s the net effect?
+* Ben
+    * The L1 norm will be 2.
+* Martin
+    * Concretely, the amount of noise will be proportional to what?
+* Ben
+    * Proportional to 2, regardless of the number of bins or the size of the histogram.
+    * For the non-negative noise, with sensitivity 2, you have an expectation n. 
+    * You then have to generate the number of events of the size of each bin, e.g. n people with 1 event, n people with 2 events (2*n events), etc. 
+    * Should actually be that they know ⅔ the noise, and multiply by 3.
+    * [Table]
+* Martin
+    * Is that a billion?!
+* Ben
+    * Yes, it really depends on the parameters
+    * Next slide for discussion, what should those parameters be?
+    * Should it factor into the budget? It’s not (intentionally) revealed to the consumer.
+* Martin
+    * Prefer this not to be deducted from the budget.
+    * Range from 1-10 is probably acceptable here.
+* Daniel
+    * Curious how this compares to other DP mechanisms.
+* Ben
+    * Can’t use regular laplace or gaussian because we can only add dummies.
+* Martin
+    * Don’t need to do this in MPC, can just do it pairwise. 
+* Daniel
+    * Is the problem with gaussian that it’s not discrete?
+* Martin
+    * Just saying we don’t need it in MPC.
+* Daniel
+    * Can’t you just round up?
+* Martin
+    * There are papers on that.
+* Ben
+    * Any thoughts on delta?
+* Martin
+    * Currently using ~10^-9 probability of detection in the implementation.
+    * Reasonably comfortable with 10^-8 or 10^-9.
+    * 1 in a million is on the edge, 
+* Ben
+    * What’s a reasonable value for the cap? It makes a big difference.
+* Erik
+    * Can’t it be configurable?
+* Martin
+    * Needs to be configured on the device.
+* Erik
+    * These epsilons are per query, so if you use your budget to run lots of queries, this will grow..
+* Martin
+    * If you’re making a query with ε=1, then the dummy event epsilon is ε*M, for some multiplier, e.g, 10. The loss towards the helper parties is worse, but we trust them somewhat.
+* Ben
+    * What if we assume multiple sites colluding with the helper?
+* Phillip
+    * One nice thing about tying it to the budget is you have a tradeoff.
+* Nick
+    * Are there important business cases where the user visits 10k times?
+* Martin
+    * I think one of the problems is that on a site like Instagram, where every nth content is an ad, and you need to throw all those in a bucket.