matrix-synapse-shared-secret-auth
Zulip
matrix-synapse-shared-secret-auth | Zulip | |
---|---|---|
1 | 117 | |
77 | 20,056 | |
- | 2.3% | |
3.7 | 10.0 | |
4 months ago | 5 days ago | |
Python | Python | |
GNU Affero General Public License v3.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
matrix-synapse-shared-secret-auth
-
Mautrix-whatsapp configuration
bridge: # Localpart template of MXIDs for WhatsApp users. # {{.}} is replaced with the phone number of the WhatsApp user. usernametemplate: whatsapp{{.}} # Displayname template for WhatsApp users. # {{.PushName}} - nickname set by the WhatsApp user # {{.BusinessName}} - validated WhatsApp business name # {{.Phone}} - phone number (international format) # The following variables are also available, but will cause problems on multi-user instances: # {{.FullName}} - full name from contact list # {{.FirstName}} - first name from contact list displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)" # Should the bridge create a space for each logged-in user and add bridged rooms to it? # Users who logged in before turning this on should run !wa sync space to create and fill the space for the first time. personal_filtering_spaces: false # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp? delivery_receipts: false # Should incoming calls send a message to the Matrix room? call_start_notices: true # Should another user's cryptographic identity changing send a message to Matrix? identity_change_notices: false portal_message_buffer: 128 # Settings for handling history sync payloads. history_sync: # Should the bridge create portals for chats in the history sync payload? create_portals: true # Enable backfilling history sync payloads from WhatsApp using batch sending? # This requires a server with MSC2716 support, which is currently an experimental feature in synapse. # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml. # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers. # There are also still some issues in Synapse's federation implementation. backfill: false # Use double puppets for backfilling? # In order to use this, the double puppets must be in the appservice's user ID namespace # (because the bridge can't use the double puppet access token with batch sending). # This only affects double puppets on the local server, double puppets on other servers will never be used. double_puppet_backfill: false # Should the bridge request a full sync from the phone when logging in? # This bumps the size of history syncs from 3 months to 1 year. request_full_sync: false # Settings for media requests. If the media expired, then it will not # be on the WA servers. # Media can always be requested by reacting with the ♻️ (recycle) emoji. # These settings determine if the media requests should be done # automatically during or after backfill. media_requests: # Should expired media be automatically requested from the server as # part of the backfill process? auto_request_media: true # Whether to request the media immediately after the media message # is backfilled ("immediate") or at a specific time of the day # ("local_time"). request_method: immediate # If request_method is "local_time", what time should the requests # be sent (in minutes after midnight)? request_local_time: 120 # The maximum number of initial conversations that should be synced. # Other conversations will be backfilled on demand when the start PM # provisioning endpoint is used or when a message comes in from that # chat. max_initial_conversations: -1 # Settings for immediate backfills. These backfills should generally be # small and their main purpose is to populate each of the initial chats # (as configured by max_initial_conversations) with a few messages so # that you can continue conversations without loosing context. immediate: # The number of concurrent backfill workers to create for immediate # backfills. Note that using more than one worker could cause the # room list to jump around since there are no guarantees about the # order in which the backfills will complete. worker_count: 1 # The maximum number of events to backfill initially. max_events: 10 # Settings for deferred backfills. The purpose of these backfills are # to fill in the rest of the chat history that was not covered by the # immediate backfills. These backfills generally should happen at a # slower pace so as not to overload the homeserver. # Each deferred backfill config should define a "stage" of backfill # (i.e. the last week of messages). The fields are as follows: # - start_days_ago: the number of days ago to start backfilling from. # To indicate the start of time, use -1. For example, for a week ago, use 7. # - max_batch_events: the number of events to send per batch. # - batch_delay: the number of seconds to wait before backfilling each batch. deferred: # Last Week - start_days_ago: 7 max_batch_events: 20 batch_delay: 5 # Last Month - start_days_ago: 30 max_batch_events: 50 batch_delay: 10 # Last 3 months - start_days_ago: 90 max_batch_events: 100 batch_delay: 10 # The start of time - start_days_ago: -1 max_batch_events: 500 batch_delay: 10 # Should puppet avatars be fetched from the server even if an avatar is already set? user_avatar_sync: true # Should Matrix users leaving groups be bridged to WhatsApp? bridge_matrix_leave: true # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices. sync_with_custom_puppets: true # Should the bridge update the m.direct account data event when double puppeting is enabled. # Note that updating the m.direct event is not atomic (except with mautrix-asmux) # and is therefore prone to race conditions. sync_direct_chat_list: false # When double puppeting is enabled, users can use !wa toggle to change whether # presence and read receipts are bridged. These settings set the default values. # Existing users won't be affected when these are changed. default_bridge_receipts: true default_bridge_presence: true # Send the presence as "available" to whatsapp when users start typing on a portal. # This works as a workaround for homeservers that do not support presence, and allows # users to see when the whatsapp user on the other side is typing during a conversation. send_presence_on_typing: false # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp) # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)? # # By default, the bridge acts like WhatsApp web, which only sends active delivery # receipts when it's in the foreground. force_active_delivery_receipts: false # Servers to always allow double puppeting from double_puppet_server_map: example.com: https://example.com # Allow using double puppeting from any server with a valid client .well-known file. double_puppet_allow_discovery: false # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth # # If set, double puppeting will be enabled automatically for local users # instead of users having to find an access token and run login-matrix # manually. login_shared_secret_map: example.com: foobar # Should the bridge explicitly set the avatar and room name for private chat portal rooms? private_chat_portal_meta: false # Should Matrix m.notice-type messages be bridged? bridge_notices: true # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run. # This field will automatically be changed back to false after it, except if the config file is not writable. resend_bridge_info: false # When using double puppeting, should muted chats be muted in Matrix? mute_bridging: false # When using double puppeting, should archived chats be moved to a specific tag in Matrix? # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix. # This can be set to a tag (e.g. m.lowpriority), or null to disable. archive_tag: null # Same as above, but for pinned chats. The favorite tag is called m.favourite pinned_tag: null # Should mute status and tags only be bridged when the portal room is created? tag_only_on_create: true # Should WhatsApp status messages be bridged into a Matrix room? # Disabling this won't affect already created status broadcast rooms. enable_status_broadcast: true # Should the status broadcast room be muted and moved into low priority by default? # This is only applied when creating the room, the user can unmute it later. mute_status_broadcast: true # Tag to apply to the status broadcast room. status_broadcast_tag: m.lowpriority # Should the bridge use thumbnails from WhatsApp? # They're disabled by default due to very low resolution. whatsapp_thumbnail: false # Allow invite permission for user. User can invite any bots to room with whatsapp # users (private chat and groups) allow_user_invite: false # Whether or not created rooms should have federation enabled. # If false, created portal rooms will never be federated. federate_rooms: true # Whether to enable disappearing messages in groups. If enabled, then the expiration time of # the messages will be determined by the first user to read the message, rather than individually. # If the bridge only has a single user, this can be turned on safely. disappearing_messages_in_groups: false # Should the bridge never send alerts to the bridge management room? # These are mostly things like the user being logged out. disable_bridge_alerts: false # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview, # and send it to WhatsApp? URL previews can always be sent using the com.beeper.linkpreviews # key in the event content even if this is disabled. url_previews: false
Zulip
- Ask HN: Open-Source Chat Platform Matrix, Rocketchat, Mattermost
-
A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev
Zulip — Real-time chat with a unique email-like threading model. The free plan includes 10,000 messages of search history and File storage up to 5 GB. also, it provides a self-hostable open-source version.
-
Ask HN: What are some unpopular technologies you wish people knew more about?
(1) Zulip Chat - https://zulip.com/ - seems to be reasonably popular, but more people should know about it
I’ve been using it for over 5 years now [1], and it’s as good as ever. It’s way faster than any other chat app I’ve used. It has a good UI and conversation model. It has a simple and functional API that lets me curl threads and write blog posts based on them.
(only problem is that I Ctrl-+ in my browser to make the font bigger – I think it’s too dense for most people)
(2) re2c regex to state machine compiler - https://re2c.org
A gem from the 90’s, which people have done a great job maintaining and improving (getting Go and Rust target support in the last few years). I started using it in 2016, and used for a new program a few months ago. I came to the conclusion that it should have been built into C, because C has shitty string processing – and Ken Thompson both invented C AND brought regular languages to computing !!
In comparison, treesitter lexers are very low level, fiddly, and error prone. I recently saw dozens of ad hoc fixes to the tree-sitter-bash lexer, which is unsurprising if you look at the structure of the code (manually crawling through backslashes and braces in C).
https://github.com/tree-sitter/tree-sitter-bash/blob/master/...
These fixes are definitely appreciated, but I think it indicates a problem with the model itself.
(based on https://lobste.rs/s/endspx/software_you_are_thankful_for#c_y...)
[1] https://www.oilshell.org/blog/2018/04/26.html
- Wog wog
- Slack Takes an Important Step to Block Abuse
- Andreas Kling – “I have received a $100k sponsorship for Ladybird browser”
-
Debate Land Beta 0.2 is out!
A few more truly in the vibe of open source projects not advertising their hosting providers: https://plane.so/ , https://element.io/ , https://www.loomio.com/ , https://zulip.com/ , and it keeps going... Very few open source projects, in the FOSS sense, are advertising their hosting provider.
-
All Your Licensing Are Belong to Us^W You
I was so excited to see this happen!
I'm not a customer of yours, but your blog posts inspired me a lot. Your journey through quitting caffeine is a great and heartening read.
I've got two things to say;
1) Will you consider source-availabling the web portal (app.keygen.sh) too? Some enterprises could use it for easy management/support for custoner's licenses. Although now that I think about it, it could also discourage custom, more suitable implementations for each use-case... I'm torn on this one. I would like to see it available on GitHub too just out of curiosity too. It's very beautiful.
2) For a team + customers' chat, I cannot recommend Zulip enough. It's a joy to use and has the most innovative chat system I've ever seen. https://zulip.com
I hope your business keeps prospering!
-
Ask HN: Who is hiring? (June 2023)
Zulip | Senior Flutter Engineer | REMOTE or San Francisco | Full-time | https://zulip.com/
At Zulip, we’re out to build the world’s best collaboration platform, and we’re committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators and communities around the world.
We're building the next generation of Zulip's mobile apps in Flutter. We're looking for a senior engineer with Flutter experience to join our small core team and help define the future of team chat. Our Flutter prototype is just a few months old, so this is a greenfield opportunity to help shape the app's architecture from early on.
For full details, check out https://zulip.com/jobs/. Apply at [email protected].
-
The Apollo social media site
Anyways, I'm an internet stranger, not a social media expert. So let me know what you all think. And if we make a discord or zulip or something to make this a reality, let me know and I'd love to help any way I can.
What are some alternatives?
signal - Online MIDI Editor: signal
Mattermost - Mattermost is an open source platform for secure collaboration across the entire software development lifecycle..
matrix-spec-proposals - Proposals for changes to the matrix specification
Rocket.Chat - The communications platform that puts data protection first.
Synapse - Synapse: Matrix homeserver written in Python/Twisted.
Matrix Console Web
signal - A Matrix-Signal puppeting bridge
Jitsi Meet - Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
whatsapp - A Matrix-WhatsApp puppeting bridge
Element - A glossy Matrix collaboration client for the web.
GrapesJS - Free and Open source Web Builder Framework. Next generation tool for building templates without coding
Live Helper Chat - Live Helper Chat - live support for your website. Featuring web and mobile apps, Voice & Video & ScreenShare. Supports Telegram, Twilio (whatsapp), Facebook messenger including building a bot.