Re: Your 90-Day Progress Report Due in January

[William Casarin]

Sorry for the delay, here's our update since our last one (Dec 5)

# Damus OpenSats Grant Dec 2024 to Jan 2025 Progress Report

This period of the Damus OpenSats grant has been productive, and encompasses the work past our alpha release of Notedeck. Since we sent our last report on Dec 5, this encompasses all the work after then.

## Damus Notedeck

### Added
- Initial algo timelines (William Casarin) [#712](https://github.com/damus-io/notedeck/pull/712)
- Initial support for local-network P2P nostr: multicast support (William Casarin) [#626](https://github.com/damus-io/notedeck/pull/626)
- First steps toward the notedeck browser: multiple app support [#565](https://github.com/damus-io/notedeck/pull/565)
- Clicking a mention now opens profile page (William Casarin) [5a241d730](https://github.com/damus-io/notedeck/commit/5a241d730e3d83f8057e211485edfde2f3c96e54)
- Note previews when hovering reply descriptions (William Casarin) [#591](https://github.com/damus-io/notedeck/pull/591)
- Various Android updates and compatibility improvements (Ken Sedgwick, William Casarin)

- Media uploads (kernelkind) [#662](https://github.com/damus-io/notedeck/pull/662)
- Profile editing (kernelkind) [#625](https://github.com/damus-io/notedeck/pull/625)
- Add hashtags to posts (Daniel Saxton) [#592](https://github.com/damus-io/notedeck/pull/592)
- Enhanced command-line interface for user interactions (Ken Sedgwick)
- Debug features for user relay-list and mute list synchronization (Ken Sedgwick)

### Changed
- Major timeline cache refactor (William Casarin) [#653](https://github.com/damus-io/notedeck/pull/653)
- Increased ping intervals for network performance (William Casarin)
- Migrated to egui v0.29.1 (William Casarin) [#551](https://github.com/damus-io/notedeck/pull/551)
- Switch to only notes & replies on some tabs (William Casarin) [#598](https://github.com/damus-io/notedeck/pull/598)
- Only show column delete button when not navigating (William Casarin)
- Pointer interactions enhancements in UI (William Casarin)
- Show profile pictures in column headers (William Casarin)
- Show usernames in user columns (William Casarin)

- Add confirmation when deleting columns (kernelkind)
- Enhance Android build and performance (Ken Sedgwick)
- Image cache handling using sha256 hash (kieran)
- Introduction of decks_cache and improvements (kernelkind)
- Nostrdb update for async support (Ken Sedgwick)
- Persistent theme setup across sessions (kernelkind)
- Tombstone muted notes (Ken)

### Fixed
- Fix GIT_COMMIT_HASH compilation issue (William Casarin)
- Fix avatar alignment in profile previews (William Casarin)
- Fix broken quote repost hitbox (William Casarin)
- Fix crash when navigating in debug mode (William Casarin)
- Fix long delays when reconnecting (William Casarin)
- Fix repost button size (William Casarin)

- Fixed since kind filters (kernelkind)
- Clippy warnings resolved (Dimitris Apostolou)

## Damus iOS

Work continued on the iOS side. While I was not directly involved in the work since the last report, I have been directing and managing its development.

### Added

- Render Gif and video files while composing posts (Swift Coder)
- Purple members who have been active for more than a year now get a special badge (Daniel D’Aquino)
- Add profile info text in stretchable banner with follow button (Swift Coder)
- Paste Gif image similar to jpeg and png files (Swift Coder)


### Changed

- Improved clarity of the mute button to indicate it can be used for blocking a user (Daniel D’Aquino)
- Made the microphone access request message more clear to users (Daniel D’Aquino)
- Improved UX around the label for searching words (Daniel D’Aquino)
- Improved accessibility support on some elements (Daniel D’Aquino)


### Fixed

- Fixed issue where the "next" button would appear hidden and hard to click on the create account view (Daniel D’Aquino)
- Fix non scrollable wallet screen (Swift Coder)
- Fixed suggested users category titles to be localizable (Terry Yiu)
- Fixed GradientFollowButton to have consistent width and autoscale text limited to 1 line (Terry Yiu)
- Fixed right-to-left localization issues (Terry Yiu)
- Fixed AddMuteItemView to trim leading and trailing whitespaces from mute text and disallow adding text with only whitespaces (Terry Yiu)
- Fixed SideMenuView text to autoscale and limit to 1 line (Terry Yiu)
- Fixed an issue where a profile would need to be input twice in the search to be found (Daniel D’Aquino)
- Fixed non-breaking spaces in localized strings (Terry Yiu)
- Fixed localization issue on Add mute item button (Terry Yiu)
- Replace non-breaking spaces with regular spaces as Apple's NSLocalizedString macro does not seem to work with it (Terry Yiu)
- Fixed localization issues in RelayConfigView (Terry Yiu)
- Fix duplicate uploads (Swift Coder)
- Remove duplicate pubkey from Follow Suggestion list (Swift Coder)
- Fix Page control indicator (Swift Coder)
- Fix damus sharing issues (Swift Coder)
- Fixed issue where banner edit button is unclickable (Daniel D’Aquino)
- Handle empty notification pages by displaying suitable text (Swift Coder)

## Nostrdb

nostrdb, the engine that powers [notecrumbs](https://github.com/damus-io/notecrumbs), damus iOS, and notedeck, continued to improve:

### Added

- Added nip50 fulltext searching (William Casarin) [#68](https://github.com/damus-io/nostrdb/pull/68), [demo](https://njump.me/nevent1qqsp3rx83t5h0vdhu4txru76uycfnaegfj3wg6wncamkarcnrccssvcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj9efqkkv)
- Added async migrations (William Casarin) [#59](https://github.com/damus-io/nostrdb/pull/59)
- Implement author queries (William Casarin) [#57](https://github.com/damus-io/nostrdb/pull/57)
- Make `ndb` threadsafe (William Casarin) [#56](https://github.com/damus-io/nostrdb/pull/56)

## Nostrdb Rust

Our nostrdb rust bindings also had improvements

- Async! Adding efficient, poll-based stream support (William Casarin): [#25](https://github.com/damus-io/nostrdb-rs/pull/25)

## Notecrumbs

Notecrumbs, the njump-style opengraph server that powers the damus.io links, got an update that upgraded it to async nostrdb

- Switch to async nostrdb-rs (William Casarin) [#16](https://github.com/damus-io/notecrumbs/pull/16)

## How money was used

- relay.damus.io server costs
- Living expenses

## Next quarter

Our goal for next update: zaps, android version, lists, outbox model for notedeck. Olas images in damus iOS, continue switching Damus iOS over to local relay model so we can add outbox support.


On Sun, Jan 19, 2025 at 12:05:40AM +1030, Lucas @ OpenSats wrote:
>Dear Grantee,
>
>This is a friendly reminder that you have a 90-day progress report due in January, which should cover your activities from October through December. If you have already sent this report or if your 1st grant payout was now in January/2024, please disregard this message. Otherwise, we’d appreciate if you could send it before the end of this month.
>
>We have also revised the template attached and added more guidance on how to build a quality progress report. Please take a moment to review and use the full template in markdown format. Let us know if you have any feedback on this template. You can also refer to the Grantee FAQ (https://opensats.org/faq/grantee) for additional information on progress reports and your grant in general.
>
>To inform the public as well as donors and the wider ecosystem, we will publish some of your progress reports as dedicated blog posts at opensats.org/blog <http://opensats.org/blog> . The blog posts will be about software and project updates only; expense statements and similar will not be included.
>
>As always, don't hesitate to reach out if you have any questions.
>
>Best regards,
>
>Lucas
>
>Operations Team
>
> <http://www.opensats.org/> OpenSats
>
>
>
>
>



>Instructions
>- Replace the information below with your project information. Example: Progress Report # 1: Feb - Apr 2024
>- Refer to our GRANTEE FAQ (https://opensats.org/faq/grantee) and/or guidelines below for additional info on how to build a quality progress report.
>- Add however many headings you would like under each section. If you require assistance from OpenSats, add any requests at the end.
>- Rename this file and reply to the email from sup...@opensats.org. No need to CC anyone.
>
>----------------------------------------------------------------------------
>
>Example: Progress Report - My Project MAY 2024
>
># PROJECT NAME
>## Progress Report # 1: Feb - Apr 2024
>
>
>## 1) How did you spend your time?
>
>
>
>## 2) What do you plan to work on next quarter?
>
>
>
>## 3) How did you make use of the money?*
>
>
>
>In case you're stuck or ran into any problems, feel free to answer a 4th question:
>
>## 4) Is there anything we could help with?**
>
>
>
>-----------------------------------------------------------------------------
>
>
>Depending on progress and project, these reports will vary in detail (and thus length). Something between one and three pages is what we're looking for, but feel free to be verbose if you have a lot to say. Please include links to changelogs, pull-requests, milestones, and anything else that might be relevant where appropriate.
>
>What does an ideal progress report look like?
>- Written in Markdown format
>- Between 1 and 3 pages
>- Enriched with the most relevant links to pull requests, commits, and other work produced
>
>In the best case, each progress report:
>- Contains properly labeled headers and sub-headers for work completed
>- Concise summary of work for each feature under each sub-header
>- Specific links to PR’s and commits listed next to the sub-headers making it easy to follow and verify
>- Tells us if you are on track
>- Describes challenges, and how you overcame them
>- Includes if you are pleased or displeased with the progress you made
>- Every progress report should show clearly the connection between what was planned in the application or previous report(s) and the work done since.
>- We encourage you to openly discuss any obstacles that may have prevented you from reaching previously established milestones, and/or why your previously outlined plans changed. Remember that we're here to help, not to judge.
>
>What does a poor progress report look like?
>- Hard to read
>- An incredibly long wall of text
>- Not showing any of the actual work done
>- Missing links to pull requests and commits
>- Missing context, summaries, and explanations, i.e. is only a long list of links to pull requests and commits without anything else
>
>(*) We need to ask (3) for legal and compliance reasons.
>If you are depending on the grant for living expenses, something like "living expenses" is fine and there is no need to specify each line of your living expenses.
>If you are using the grant to purchase products and services related to the work being done under the grant, a more detailed breakdown of cost categories is required, including but not limited to:
>- Office expenses
>- Travel for conferences and meet-ups
>- Server costs
>- Payments to project contributors
>We strongly encourage you to keep records. Receipts (for AWS bills, computers, supplies, etc.), invoices (attending or putting on a conference), or banking and other statements (paying for living expenses). Given our 501(c)(3) non-profit status, if OpenSats ever goes through an audit, you must be able to send the information to support the use of your grant proceeds, and that information could be in pretty much any form as mentioned (receipts, invoices, bank statements, credit card statements, etc.).
>
>(**) In case your troubles are related to design, please know that we launched a design initiative: https://opensats.org/blog/announcing-nostr-design - the initiative is mainly focused on nostr, but feel free to reach out to des...@opensats.org with any design & UI/UX related questions and inquiries for general bitcoin software too.
>

[Lucas @ OpenSats]

Thanks Will and team!

Lucas
Operations Team
OpenSats

[Lucas @ OpenSats]

Hi Will,

Just a constructive feedback around the structure of the report.

We would prefer a few paragraphs describing what is new and why it is
important, or why they were complex to implement, instead of a long list of
commits, often not so interesting. The links are important and make our
review process a lot easier, but it would also help to focus only on the
most relevant parts of the work for each report, adding some context about
those parts.

Hopefully this approach can make the process of writing these reports less
time consuming, we really don't want the reports to be a hurdle for you.

Please find more guidance about progress reports here:
https://opensats.org/faq/grantee#what-does-an-ideal-progress-report-look-lik
e
https://opensats.org/faq/grantee#what-does-a-poor-progress-report-look-like

Thank you,

Lucas
Operations Team
OpenSats

-----Original Message-----
From: William Casarin <jb...@jb55.com>
Sent: Sunday, 9 February 2025 6:58 AM
To: Lucas @ OpenSats <lu...@opensats.org>
Cc: 'Support' <sup...@opensats.org>; d...@damus.io; van...@damus.io
Subject: Re: Your 90-Day Progress Report Due in January

[Lucas @ OpenSats]

By the way, no need to revise this report, just something to consider for
the next ones.
Thanks again,

[William Casarin]

On Tue, Feb 11, 2025 at 05:36:19PM +1030, 'Lucas @ OpenSats' via dev wrote:
>By the way, no need to revise this report, just something to consider for
>the next ones.
>Thanks again,
>
>Lucas
>Operations Team
>OpenSats

For what its worth this is our changelog, not commits. The purpose of it
is a summary of all of the things that are new and have changed, with
attached PRs as requested. It is already a summarized version of all the
individual commits.

I will try to add additional higher level descriptions alongside the
changelog next time.

Cheers,
Will

[Lucas @ OpenSats]

Thanks Will, appreciate it!