Skip to content

Discussion: Ideas, introductions and notes for Taskserver ccsync in GSoC'27 #297

Open

Description

@its-me-abhishek

Description
This discussion thread is for brainstorming features, integrations, and UX enhancements that we could implement for ccsync as part of GSoC 2027. Everyone is encouraged to propose, refine, and discuss ideas in preparation. The discussion might be related to any of these ideas or new ones, and their implementations, etc. Please do not share your personal information, proposals, art, anything that might be useful, etc. here.

Contributors can also use this thread to briefly introduce themselves and/or represent their interests or skills relevant to GSoC 2027 with CCSync.

Expected Output

  • A list of proposed ideas, feature requests, integration plans, UX suggestions, and contributor interests for GSoC 2027 (not all ideas may be implemented).
  • Clarification, refinement, and prioritization of possible directions for ccsync
  • Placeholder only: no implementation or assignment of work unless ideas are moved to tracked issues, after further review

Feature & UX Ideas for now (all these are part of the same project)

  1. Data Visualization & UX (Medium/High Priority)

    • Kanban & Calendar Views using projects: Moving beyond lists to project-based boards and time-based scheduling.
    • Task Graph Flow Diagram: A semantic graph (using Cytoscape.js or D3.js) showing dependencies, project clusters, and tag relationships.
    • Advanced Theming: High-contrast modes, adjustable typography, and persistent light/dark themes.
    • Text to speech: Add a native TTS module, that dictates the texts of each task Dialog, on demand. Would make it easier to navigate across tasks
  2. Ecosystem & Integrations (Medium/High Priority)

    • Centralized Sync Hub: Expanding 2-way sync for Google Tasks (priority), Google Calendar, Jira, and Joplin.
    • Code Host Integration: Integration with GitHub/GitLab issues via Bugwarrior.
    • Notification Engine: External reminders via Email (likely by extending the backend CLI).
    • Updated Documentation for all the new changes
  3. Core & Performance (Medium)

    • PWA Support: Offline usage via Web Workers for a desktop/mobile app-like experience.
    • Account Portability: Tools for bulk transfer, deletion, or UUID migration between accounts.
    • Mock Demo Instance: A "Try Before You Login" feature using a mock frontend implementation that doesn't require real auth. It can include a sample user with secrets, etc. Some tasks, similar to the real HomePage
  4. Task Graph Flow Diagram Idea: Semantic “task graph” with visual connections

    • Nodes = tasks, Edges = dependencies/project/tag sharing
    • Different line styles for each relation, interactive exploration (Cytoscape.js/D3.js)
    • Node color/border for project/priority, hover/click for task info, mini-map overview, filters for graph layers
    • Optional: visual effects (aging, completion, AI “theme” nodes)
    • Implementation path: preprocess tasks in browser, render with react-cytoscapejs, style by edge type, add filtering/interactions.

Feel free to DM me on Zulip for any discussion related to proposals, etc.

Important Links

NOTE: This list is not exhaustive; additional ideas may be proposed, and some items listed here may be deprioritized or removed over time. The scope (hours required) can thus be decided for the project once these are finalized. Please use this thread strictly for discussion and brainstorming. Since this is not a tracked issue, it is not assignable, and contributors are requested not to start implementation work based on these ideas at this stage.

Activity

  1. added
    discussionOnly a thread for Discussion, unassignable!
    GSoCGoogle Summer of Code related
    on Dec 23, 2025
  2. its-me-abhishek commented on Dec 23, 2025

    @its-me-abhishek
    CollaboratorAuthor

    Another thread relevant for Discussions related to integrations #142

  3. Hell1213 commented on Dec 24, 2025

    @Hell1213
    Contributor

    hey @its-me-abhishek ,
    I am Rajat. I’ve been contributing to CCsync for a while now across frontend and UI work, some backend-related changes, and a bit of developer workflow/tooling.

    I’m interested in participating in GSoC 2026 with CCsync and will be following this thread to understand priorities and help refine ideas, especially around integrations and building things that are realistic to implement and ship within a GSoC timeline.

    Looking forward to the discussions here.

  4. jnakaigen commented on Dec 24, 2025

    @jnakaigen

    Hi @its-me-abhishek and community! I'm Janaki. I'm a student interested in contributing to CCSync for GSoC 2026. While I'm new to this specific codebase, I have experience with TypeScript and REST APIs. I'm currently setting up the development environment locally and looking through the documentation to see where I can help with initial small fixes or improvements. I'm particularly interested in the Ecosystem & Integrations ideas mentioned above!

  5. Sparshagarwal29 commented on Dec 24, 2025

    @Sparshagarwal29
    Contributor

    Hi @its-me-abhishek and everyone,

    I’m Sparsh, a student interested in getting involved with CCSync and learning more about the project in the context of GSoC 2026. I’ve recently started exploring the repository and documentation to understand how the system is structured
    I have experience working with TypeScript, web technologies, and REST-based services, and I’m in the process of setting up the project locally so I can start engaging with the code more directly. I’m open to contributing across different areas of the project and helping out with initial fixes or improvements as ideas evolve here.

    Looking forward to following the discussion and learning from the community

  6. Vasist10 commented on Dec 24, 2025

    @Vasist10
    Contributor

    Hi @its-me-abhishek ,
    I am vasist ,I’ve been contributing to CCSync recently and wanted to express my interest in the GSoC 2026 discussions.
    I’m particularly interested in backend and sync architecture (task modeling, adapters, conflict handling), and I’m following this thread to better understand possible directions and where I can be helpful.
    Looking forward to learning more and contributing!

  7. SGI-CAPP-AT2 commented on Dec 25, 2025

    @SGI-CAPP-AT2
    Contributor

    @its-me-abhishek, I think we should use taskchampion crate instead of using taskwarrior command line tool.
    There is problem of having no control on uuid when task is created. Whenever task is created at mobile application we do not have a robust key to access it.
    This problem can be eliminated by using taskchampion crate.

  8. its-me-abhishek commented on Dec 25, 2025

    @its-me-abhishek
    CollaboratorAuthor

    @SGI-CAPP-AT2
    When you say “no control on UUID,” are you referring to the pre-sync state where the task hasn’t received a UUID yet?

    I checked the taskchampion docs Task struct, and it seems like this pre-sync issue can be addressed by using the crate directly. Maybe using the same backend, using ffi or similar stuff.

    Also, I’m quite a bit unsure whether adopting taskchampion adds another layer of friction for users especially those who already have taskc servers set up with on their systems, and use CCSync as a web/app extension. I think this Remote ServerConfig could fix this (need to test this out)

    My thoughts: One simpler workaround could be to automatically trigger a re-sync right after task creation, so the backend returns the fully populated task (with UUID) instead of the skeletal pre-sync task. The tradeoff would be one extra API call per task creation.

    Curious about how you might be thinking of implementing this. IMO we can and should go through this in case the performance, response rates by using crates are better than that add-re-sync workflow else the current implementation seems to be fine and can be fixed via that workaround. One thing I am concerned about is that -- that CLI implementation is kinda hard to go obsolete and is more robust (as TW2.0 got deprecated earlier and so did taskd). For example- if and when TW3.0+taskchampion combination is deprecated similar to that TW2.0, we can switch to that version by just patching how the sync works, which might not be the case with taskchampion crate.

    EDIT: username tag and some context

  9. SGI-CAPP-AT2 commented on Dec 25, 2025

    @SGI-CAPP-AT2
    Contributor

    When you say “no control on UUID,” are you referring to the pre-sync state where the task hasn’t received a UUID yet?

    Yes, Exactly

    Also, I’m quite a bit unsure whether adopting taskchampion adds another layer of friction for users especially those who already have taskc servers set up with on their systems, and use CCSync as a web/app extension. I think this Remote ServerConfig could fix this (need to test this out)

    We're already using ServerConfig in Mobile Application and this works with CCSync. The creds provided by the CCSync can be used to sync with that Sync Server Profile Mode (Taskchampion (v3)). These tasks are synced with both Server Profile modes (CCsync and Taskchampion) and on CCsync web (which makes it working on CLI as well).

    My thoughts: One simpler workaround could be to automatically trigger a re-sync right after task creation, so the backend returns the fully populated task (with UUID) instead of the skeletal pre-sync task. The tradeoff would be one extra API call per task creation.

    What if server is not available or user currently have no network to access server, in such case Task shows no UUID. these can only be fixed on next sync.
    And i think the client should have fully populated task without a sync. That's how Application works with TW2.0 and Taskchampion(v3) Profile modes.

    Curious about how you might be thinking of implementing this

    In the Application, to support TaskChampion I have used FFI bindings for this crate similarly we can replace cmd module to use the crate.
    We'll maintain a Replica on CCsync server which can be Read/Wrote by the crate.

    Edit: For multiuser I think we'll need to use File System as we can can not manipulate Replica Storage without crate.

  10. Hell1213 commented on Dec 27, 2025

    @Hell1213
    Contributor

    Hey @its-me-abhishek,

    I have been looking at the Ecosystem & Integrations section and it really sticks out to me as the next big step for CCSync. Since I’ve spent time in the backend and frontend already, I’ve noticed we currently treat sync as a 'internal' loop between our own clients.

    My suggestion for the Sync Hub is to build a dedicated 'Integrations Manager' service in the Go backend. Right now, our sync logic is very tied to Taskwarrior's structure. If we create a separate layer that maps external APIs (like Google Tasks or Jira) into our internal task format, we can keep the core sync logic clean without bloating it with third-party SDKs.

    For the Notification Engine, I think the value is in moving it away from the clients. If the backend handles the reminders, we can support things like Slack or Email updates even when the user doesn't have the web or mobile app open.

    I really interested in building out the foundation for this. Do you see this as a separate microservice, or should we keep it as a module within the main backend for now?"

  11. ParasKhandelwal1616 commented on Dec 27, 2025

    @ParasKhandelwal1616
    Contributor

    Hi @its-me-abhishek and the CCExtractor community,
    I’m Paras Khandelwal, a returning contributor to CCExtractor. I have previously worked within the organization, and I’m excited to dive into CCSync for GSoC 2026.
    I’m a 3rd-year CS student at MITS Gwalior with a strong background in the MERN stack and TypeScript. Based on my experience building enterprise-grade billing modules and real-time notification systems during my internship at CRITSO, I am particularly interested in:
    Data Visualization (High Priority): I have extensive experience with React.js and Redux and would love to implement the Kanban/Calendar views or the Task Graph using Cytoscape.js as discussed in the ideas list.
    Ecosystem Integrations: My experience with FastAPI and Node.js makes me a great fit for building the 2-way sync for Google Tasks/Jira or expanding the Notification Engine for Slack and Telegram.
    I’ve already started looking into the codebase to see how it differs from my previous work in the org. I'm looking forward to participating in the brainstorming and refining these features further!

  12. its-me-abhishek commented on Dec 27, 2025

    @its-me-abhishek
    CollaboratorAuthor

    Do you see this as a separate microservice, or should we keep it as a module within the main backend for now?

    All the integrations probably can be done similar but separate to how we are using Taskwarrior inside the backend. This will help in easily allowing a user to opt-out of them as per requirements, as the project mainly revolves around Taskwarrior sync. So introducing these as extensible adapters to the already available taskchampion sync server, which is the central point for all sync activities

  13. Hell1213 commented on Dec 27, 2025

    @Hell1213
    Contributor

    Do you see this as a separate microservice, or should we keep it as a module within the main backend for now?

    All the integrations probably can be done similar but separate to how we are using Taskwarrior inside the backend. This will help in easily allowing a user to opt-out of them as per requirements, as the project mainly revolves around Taskwarrior sync. So introducing these as extensible adapters to the already available taskchampion sync server, which is the central point for all sync activities

    That approach makes total sense—keeping the integrations separate as extensible adapters is definitely the cleanest way to do it. It protects the core taskchampion sync server and ensures we don't add unnecessary friction for people who just want a standard Taskwarrior setup.
    I really like the 'opt-out' idea too; making these optional via config would keep the backend lightweight and only run what the user actually needs. I'll spend some time looking into the existing sync server logic to see how an adapter pattern would fit in best. Definitely a good direction to brainstorm further.

  14. gaurav02081 commented on Jan 12, 2026

    @gaurav02081
    Contributor

    Hi @its-me-abhishek and CCSync community —
    I am Gaurav Karmakar, a returning OSS contributor (I’ve merged 1–2 PRs in CCExtractor) and currently a full-stack developer at an IIT Bombay startup. I am in my 6th semester of BCA.

    My tech-stacks
    angular.js (typescript ) , django rest api and Postgres , comfortable working on tmux remote Linux servers

    i have been running CCSync locally , based on that usage, a few focused areas stood out to me:

    Notifications: Backend-driven reminders (Email / Slack / Telegram) so users can receive alerts even when clients aren’t running.

    Sync visibility & transparency: While using CCSync locally, it’s not always obvious what was last synced or from where. Simple sync status info (last sync time, source like Taskwarrior vs external adapter) would be very helpful.

    Developer / power-user tooling: Lightweight debug visibility such as a small debug view or CLI flags to inspect sync state, along with clearer log/error surfacing in the UI.

    Import / export quality-of-life: Simple JSON export for backup and the ability to import sample tasks for testing and onboarding.

  15. its-me-abhishek commented on Jan 16, 2026

    @its-me-abhishek
    CollaboratorAuthor

    Added a new feature idea, might be useful for increasing accessibility-> Text to speech: Add a native TTS module, that dictates the texts of each task Dialog, on demand. Would make it easier to navigate across tasks. Provided the UI should be intuitive, and easy to use (Play-Pause-Adjust speeds, etc.)

  16. HarshRaj29004 commented on Jan 30, 2026

    @HarshRaj29004
    Contributor

    Hi everyone!
    I’m Harsh Raj, an ECE undergraduate from IIIT Kota (6th semester), exploring the possibility of contributing to CCSync. I’ve worked with React, TypeScript, and Python-based backends.

    I’m particularly interested in Ecosystem & Integrations, especially the Notification Engine and Text-to-Speech, and I’m here to learn more about the project direction and ongoing discussions.

    Looking forward to contributing and learning from the community!

  17. changed the title [-]Discussion: Ideas, introductions and notes for Taskserver ccsync in GSoC'26[/-] [+]Discussion: Ideas, introductions and notes for Taskserver ccsync in GSoC'27[/+] on Sep 5, 2026
  18. NaitikVerma6776 commented on Sep 6, 2026

    @NaitikVerma6776
    Contributor

    Hi @its-me-abhishek , I am Naitik Verma
    Contributed a small fix earlier (#470, the landing-page redirect + ENV=production session cookie thing) and got a PR merged in ccextarctor ....I have genuinely loved the organization and wanted to contribute to it for a longer term.so figured I'd drop my thoughts here too.
    The Task Graph idea is the one I'd want to dig into. Feels like it doesn't need a whole new page/route either — could just sit as another mode next to the table/reports toggle already on the tasks page. The depends field is already on the task model and there's already cycle detection happening on the backend side, so a lot of the hard part is kind of already done, just needs a view on top of it. Would probably reach for Cytoscape over D3 for the actual graph rendering.

    One open question though — should this pull straight from the tasks already loaded on the frontend, or would it make more sense to have a dedicated endpoint return the nodes/edges (and reuse the existing cycle detection logic instead of redoing it in TS)? Curious what the preference is there before anyone commits to an approach.

    Kanban/calendar could probably hang off the same view-switcher too as a later addition, reusing status/project/due fields that already exist — seems more additive than a separate effort.

    Not as sure about the sync integrations (Google/Jira/Joplin) or PWA support though, those feel like they'd need to fight the current setup (task data lives via CLI + temp dirs, not a persistent DB) more than work with it.

    Anyway, happy to help think through scope on any of this, and will keep an eye out for smaller issues to pick up in the meantime regardless of where this lands. 😊

  19. RohitSutar1823 commented on Nov 1, 2026

    @RohitSutar1823

    Hi everyone, I'm Rohit, a second-year Computer Engineering student at VIT Mumbai. I work mainly in Java and JavaScript/React, and I'm learning Node.js/Express and backend development. Go is new to me.

    I've opened one PR on ccsync so far (#477, task hotkey scoping) and I'm reading the backend, especially the job queue, to understand how sync works.

    I'm interested in contributing during the lead-up to GSoC 2027. @its-me-abhishek, could you tell me:

    1. whether ccsync is planning to apply under CCExtractor for 2027, and whether a 2027 ideas list exists yet?
    2. whether backend-reliability work (like the persistent job queue in Persistent Job Queue & Maintenance Worker for backend #367) fits a GSoC project, or if the focus is the feature ideas in this thread?
    3. what you'd like to see from contributors before proposals, beyond small PRs?

    Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GSoCGoogle Summer of Code relateddiscussionOnly a thread for Discussion, unassignable!

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions