removed Waku ref + add GitHub icon

docs/overview/concepts/content-topics.md

@@ -2,7 +2,7 @@
 title: Content Topics
 ---
 
-`Content Topics` are metadata strings set by developers on outgoing messages to facilitate protocol-level features like selectively processing incoming messages ([Relay](/overview/concepts/protocols#waku-relay) or [Filter](/overview/concepts/protocols#waku-filter)) and retrieving historical messages ([Store](/overview/concepts/protocols#waku-store)) that meet specific filtering criteria. Please refer to the [WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification to learn more.
+`Content Topics` are metadata strings set by developers on outgoing messages to facilitate protocol-level features like selectively processing incoming messages ([Relay](/overview/concepts/protocols#relay) or [Filter](/overview/concepts/protocols#filter)) and retrieving historical messages ([Store](/overview/concepts/protocols#store)) that meet specific filtering criteria. Please refer to the [WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification to learn more.
 
 ## Content Topic Format
 

docs/overview/concepts/network-domains.md

@@ -12,13 +12,13 @@ Node discovery in Waku facilitates locating other nodes within the network. As a
 
 Gossipsub derives its name from the practice within Pub/Sub networks where peers gossip about the messages they have encountered, thus establishing a message delivery network.
 
-Waku employs gossiping through [`Waku Relay`](/overview/concepts/protocols#waku-relay) to distribute messages across the network. Additionally, Waku introduces [`Waku RLN Relay`](/overview/concepts/protocols#waku-rln-relay), an experimental mechanism that combines privacy preservation and economic spam protection.
+Waku employs gossiping through [`Relay`](/overview/concepts/protocols#relay) to distribute messages across the network. Additionally, Waku introduces [`RLN Relay`](/overview/concepts/protocols#rln-relay), an experimental mechanism that combines privacy preservation and economic spam protection.
 
 ## Request/Reply Domain
 
 Waku provides a set of Request/Reply protocols to optimize its performance in resource-restricted environments like low bandwidth or offline scenarios.
 
-These protocols serve multiple purposes. [`Waku Store`](/overview/concepts/protocols#waku-store) enables the retrieval of historical messages, [`Waku Filter`](/overview/concepts/protocols#waku-filter) efficiently retrieves a subset of messages to conserve bandwidth, and [`Waku Light Push`](/overview/concepts/protocols#waku-light-push) facilitates message publication for nodes with limited bandwidth and short connection windows.
+These protocols serve multiple purposes. [`Store`](/overview/concepts/protocols#store) enables the retrieval of historical messages, [`Filter`](/overview/concepts/protocols#filter) efficiently retrieves a subset of messages to conserve bandwidth, and [`Light Push`](/overview/concepts/protocols#light-push) facilitates message publication for nodes with limited bandwidth and short connection windows.
 
 ## Overview of Protocol Interaction
 
@@ -46,7 +46,7 @@ E ->> D: HistoryQuery(pubtopic1, contentTopic1) (6)
 D ->> E: HistoryResponse(msg1, ...) (6)
 ```
 
-The Pub/Sub topic `pubtopic1` serves as a means of routing messages (the network employs a default pubsub topic) and indicates that it is subscribed to messages on that topic for a relay. In the context of Waku Store, Node D is responsible for persisting these messages.
+The Pub/Sub topic `pubtopic1` serves as a means of routing messages (the network employs a default pubsub topic) and indicates that it is subscribed to messages on that topic for a relay. Node D serves as a `Store` and is responsible for persisting messages.
 
 1. Node A creates a WakuMessage `msg1` with a [ContentTopic](/overview/concepts/content-topics) `contentTopic1`.
 2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will forward messages that match that filter in the future.

docs/overview/concepts/node-discovery.md

@@ -6,9 +6,9 @@ When initializing a Waku node, it must connect with other nodes to enable messag
 
 After establishing a connection, the node must actively seek out additional peers to have:
 
-- Sufficient peers in the [Waku Relay](/overview/concepts/protocols#waku-relay) mesh: The goal is to have at least 6 peers in the mesh. This ensures a robust network where messages can be efficiently relayed.
+- Sufficient peers in the [Relay](/overview/concepts/protocols#relay) mesh: The goal is to have at least 6 peers in the mesh. This ensures a robust network where messages can be efficiently relayed.
 - Reserve peers for backup: It is essential to have a surplus of peers available as reserves. These reserves are backups when the current peers become overloaded or experience unexpected disconnections.
-- Peers with specific Waku capabilities: The node seeks out peers with specific Waku capabilities, such as [Store](/overview/concepts/protocols#waku-store), [Light Push](/overview/concepts/protocols#waku-light-push), or [Filter](/overview/concepts/protocols#waku-filter). This allows for targeted interactions and enhanced functionality based on the desired capabilities.
+- Peers with specific capabilities: The node seeks out peers with specific capabilities, such as [Store](/overview/concepts/protocols#store), [Light Push](/overview/concepts/protocols#light-push), or [Filter](/overview/concepts/protocols#filter). This allows for targeted interactions and enhanced functionality based on the desired capabilities.
 
 ## Predefined Nodes
 
@@ -58,7 +58,7 @@ This bootstrapping method allows anyone to register and publish a domain name fo
 
 ## [Peer Exchange](https://rfc.vac.dev/spec/34/)
 
-The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on [Discv5](#discv5).
+The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on `Discv5`.
 
 #### Pros
 

docs/overview/concepts/protocols.md

@@ -4,38 +4,38 @@ title: Protocols
 
 Waku takes a modular approach, providing a range of protocols that enable applications to control the trade-offs involved in the [Anonymity Trilemma](https://eprint.iacr.org/2017/954.pdf). This flexibility empowers applications to make informed choices regarding the desired balance between anonymity, scalability, and latency. Here are the main protocols provided by Waku:
 
-## [Waku Relay](https://rfc.vac.dev/spec/11/)
+## [Relay](https://rfc.vac.dev/spec/11/)
 
-`Waku Relay` is a privacy-focused peer-to-peer messaging protocol that extends the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). It utilizes a Pub/Sub architecture to enable secure communication channels, encryption, and protection against censorship. With a strong emphasis on privacy, `Waku Relay` ensures scalability, allowing many peers and messages to coexist within the network.
+`Relay` is a privacy-focused peer-to-peer messaging protocol that extends the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). It utilizes a Pub/Sub architecture to enable secure communication channels, encryption, and protection against censorship. With a strong emphasis on privacy, `Relay` ensures scalability, allowing many peers and messages to coexist within the network.
 
-## [Waku Filter](https://rfc.vac.dev/spec/12/)
+## [Filter](https://rfc.vac.dev/spec/12/)
 
-`Waku Filter` is a protocol enabling peers to subscribe to specific messages from other peers. It is designed for devices with limited bandwidth, serving as a lighter alternative to [Waku Relay](#waku-relay). Unlike relay nodes, `Waku Filter` allows light nodes to subscribe to service nodes and receive only the messages they are interested in. This optimizes bandwidth consumption but may involve privacy compromises. Nonetheless, `Waku Filter` efficiently delivers desired messages within bandwidth constraints.
+`Filter` is a protocol enabling peers to subscribe to specific messages from other peers. It is designed for devices with limited bandwidth, serving as a lighter alternative to `Relay`. Unlike relay nodes, `Filter` allows light nodes to subscribe to service nodes and receive only the messages they are interested in. This optimizes bandwidth consumption but may involve privacy compromises. Nonetheless, `Filter` efficiently delivers desired messages within bandwidth constraints.
 
-## [Waku Store](https://rfc.vac.dev/spec/13/)
+## [Store](https://rfc.vac.dev/spec/13/)
 
-`Waku Store` is a protocol that allows the querying of messages received through the relay protocol and stored by nodes. It supports retrieving historical messages with pagination. Unlike [Waku Relay](#waku-relay), which doesn't save messages for offline users, `Waku Store` peers retain relayed messages for later retrieval.
+`Store` is a protocol that allows the querying of messages received through the relay protocol and stored by nodes. It supports retrieving historical messages with pagination. Unlike `Relay`, which doesn't save messages for offline users, `Store` peers retain relayed messages for later retrieval.
 
 :::info
-Data availability is not guaranteed with `Waku Store`. [Waku Relay](#waku-relay) or [Waku Filter](#waku-filter) are preferred for online usage, while `Waku Store` is suitable for retrieving messages after reconnecting to the network, like when a dApp starts.
+Data availability is not guaranteed with `Store`. `Relay` or `Filter` are preferred for online usage, while `Store` is suitable for retrieving messages after reconnecting to the network, like when a dApp starts.
 :::
 
-## [Waku Light Push](https://rfc.vac.dev/spec/19/)
+## [Light Push](https://rfc.vac.dev/spec/19/)
 
-`Waku Light Push` is a [Request/Reply](/overview/concepts/network-domains#requestreply-domain) protocol for Waku's light nodes with limited bandwidth and short connection windows. It enables clients to receive a confirmation when sending messages, indicating that at least one node has received them. However, using `Waku Light Push` compromises privacy as the remote peer becomes aware of the message originator.
+`Light Push` is a [Request/Reply](/overview/concepts/network-domains#requestreply-domain) protocol for Waku's light nodes with limited bandwidth and short connection windows. It enables clients to receive a confirmation when sending messages, indicating that at least one node has received them. However, using `Light Push` compromises privacy as the remote peer becomes aware of the message originator.
 
 :::info
-Please note that `Waku Light Push` confirms receipt by the remote peer but doesn't guarantee network-wide propagation.
+Please note that `Light Push` confirms receipt by the remote peer but doesn't guarantee network-wide propagation.
 :::
 
-## [Waku Message](https://rfc.vac.dev/spec/14)
+## [Message](https://rfc.vac.dev/spec/14)
 
-`Waku Message` specifies the message structure used in the Waku network. It defines metadata fields, such as content topics and timestamps, that other Waku protocols can use.
+`Message` specifies the message structure used in the Waku network. It defines metadata fields, such as content topics and timestamps, that other Waku protocols can use.
 
-## [Waku Payload](https://rfc.vac.dev/spec/26)
+## [Payload](https://rfc.vac.dev/spec/26)
 
-`Waku Payload` provides guidelines for implementing secure and private communication in the Waku network. It covers encryption, decryption, and signing methods for message payloads, focusing on confidentiality, authenticity, integrity, and unlinkability.
+`Payload` provides guidelines for implementing secure and private communication in the Waku network. It covers encryption, decryption, and signing methods for message payloads, focusing on confidentiality, authenticity, integrity, and unlinkability.
 
-## [Waku RLN Relay](https://rfc.vac.dev/spec/17/)
+## [RLN Relay](https://rfc.vac.dev/spec/17/)
 
-The `Waku RLN Relay` protocol extends the [Waku Relay](#waku-relay) protocol by adding spam protection using [Rate Limiting Nullifiers (RLN)](https://rfc.vac.dev/spec/32/). It enforces a global messaging rate for all peers to prevent spam in the Waku network. Spammers face financial penalties and removal from the system. This protocol provides efficient and economic spam prevention suitable for resource-constrained environments.
+The `RLN Relay` protocol extends the `Relay` protocol by adding spam protection using [Rate Limiting Nullifiers (RLN)](https://rfc.vac.dev/spec/32/). It enforces a global messaging rate for all peers to prevent spam in the Waku network. Spammers face financial penalties and removal from the system. This protocol provides efficient and economic spam prevention suitable for resource-constrained environments.

docs/overview/index.md

@@ -51,13 +51,13 @@ These options are part of the [Anonymity Trilemma](https://eprint.iacr.org/2017/
 
 ## How Does Waku Work?
 
-The [Waku Relay](/overview/concepts/protocols#waku-relay) protocol is the foundation of the Waku network, which employs a Pub/Sub architecture built on the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). Additionally, various other Waku protocols have been created to facilitate specific functionalities, including but not limited to:
+The [Relay](/overview/concepts/protocols#relay) protocol is the foundation of the Waku network, which employs a Pub/Sub architecture built on the [libp2p GossipSub protocol](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md). Additionally, various other Waku protocols have been created to facilitate specific functionalities, including but not limited to:
 
 1. Facilitating the retrieval of historical messages for primarily offline devices.
 2. Providing solutions for encrypted communication, such as symmetric encryption, ECIES/asymmetric encryption, and noise handshake-based key turns.
 3. Preserving bandwidth usage for resource-limited environments.
 4. Implementing economic spam protection (rate limits) while ensuring privacy.
 5. Developing methods to protect against mass deanonymization (currently being researched).
-6. Designing strategies to scale `Waku Relay/GossipSub` securely.
+6. Designing strategies to scale `Relay/GossipSub` securely.
 
 If you want to learn more about how Waku operates, the [WAKU2 RFC](https://rfc.vac.dev/spec/10/) provides an in-depth look under the hood.

docs/overview/reference/research-in-progress.md

@@ -6,7 +6,7 @@ The following features are currently experimental and under research and initial
 
 ## Economic Spam Resistance
 
-We aim to enable an incentivized spam protection technique to enhance `Waku Relay` by using rate limiting nullifiers. More details on this can be found in [WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17). In this advanced method, peers are limited to a certain rate of messaging per epoch and an immediate financial penalty is enforced for spammers who break this rate.
+We aim to enable an incentivized spam protection technique to enhance `Relay` by using rate limiting nullifiers. More details on this can be found in [WAKU2-RLN-RELAY](https://rfc.vac.dev/spec/17). In this advanced method, peers are limited to a certain rate of messaging per epoch and an immediate financial penalty is enforced for spammers who break this rate.
 
 We have prepared a PoC implementation of this method in JS: <https://examples.waku.org/rln-js/>
 
@@ -14,7 +14,7 @@ We have prepared a PoC implementation of this method in JS: <https://examples.wa
 
 Denial of service signifies the case where an adversarial node exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can tracked from here: <https://github.com/vacp2p/research/issues/148>.
 
-In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivizing the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Waku Store` and `Waku Filter` to protect against DoS attacks.
+In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivizing the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks.
 
 Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: <https://vac.dev/building-privacy-protecting-infrastructure>
 

docs/overview/reference/security-features.md

@@ -14,14 +14,14 @@ Waku ensures pseudonymity across its protocol layers, using libp2p `PeerID` as i
 
 Anonymity means an adversary cannot connect an actor to their actions or data. To achieve anonymity, avoiding linking activities with actors or their Personally Identifiable Information (PII) is crucial. In Waku, the following anonymity features are provided:
 
-- [Publisher-Message Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the publisher of messages in the `Waku Relay` protocol cannot be linked to their published messages.
+- [Publisher-Message Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the publisher of messages in the `Relay` protocol cannot be linked to their published messages.
-- [Subscriber-Topic Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the subscriber of topics in the `Waku Relay` protocol cannot be linked to the topics they have subscribed to.
+- [Subscriber-Topic Unlinkability](https://rfc.vac.dev/spec/11/#security-analysis): Ensures that the subscriber of topics in the `Relay` protocol cannot be linked to the topics they have subscribed to.
 
 ## [Spam Protection](https://rfc.vac.dev/spec/10/#spam-protection)
 
-The spam protection feature in `Waku Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behavior and remove peers with low scores.
+The spam protection feature in `Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behavior and remove peers with low scores.
 
-Ongoing research is being conducted, including developing [Rate Limiting Nullifiers (RLN)](/overview/concepts/protocols#waku-rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
+Ongoing research is being conducted, including developing [Rate Limiting Nullifiers (RLN)](/overview/concepts/protocols#rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
 
 ## [Data Confidentiality, Integrity, and Authenticity](https://rfc.vac.dev/spec/10/#data-confidentiality-integrity-and-authenticity)
 
@@ -29,4 +29,4 @@ Confidentiality in Waku is ensured through data encryption, while integrity and
 
 ## [Security Considerations](https://rfc.vac.dev/spec/10/#security-considerations)
 
-In protocols like `Waku Store` and `Waku Filter`, where direct connections are required for the designated service, anonymity or unlinkability is not guaranteed. This is because peers use their `PeerID` to identify each other during direct connections, making the service obtained in these protocols linkable to the beneficiary's `PeerID`, considered Personally Identifiable Information (PII). In `Waku Store`, the queried node can link the querying node's `PeerID` to the topics being queried. Similarly, in `Waku Filter`, a full node can link the `PeerID` of a light node to its content filter.
+In protocols like `Store` and `Filter`, where direct connections are required for the designated service, anonymity or unlinkability is not guaranteed. This is because peers use their `PeerID` to identify each other during direct connections, making the service obtained in these protocols linkable to the beneficiary's `PeerID`, considered Personally Identifiable Information (PII). In `Store`, the queried node can link the querying node's `PeerID` to the topics being queried. Similarly, in `Filter`, a full node can link the `PeerID` of a light node to its content filter.

docs/overview/reference/waku-vs-libp2p.md

@@ -12,8 +12,8 @@ Waku intends to incentivize mechanisms to run nodes, but it's not part of libp2p
 
 Waku includes various protocols covering the following domains: privacy preservation, censorship resistance, and platform agnosticism, allowing it to run on any platform or environment.
 
-libp2p does not provide out-of-the-box protocols to enable mostly offline/resource-restricted devices, [Waku Store](/overview/concepts/protocols#waku-store)/[Waku Light Push](/overview/concepts/protocols#waku-light-push)/[Waku Filter](/overview/concepts/protocols#waku-filter) caters to those use cases.
+libp2p does not provide out-of-the-box protocols to enable mostly offline/resource-restricted devices, [Store](/overview/concepts/protocols#store)/[Light Push](/overview/concepts/protocols#light-push)/[Filter](/overview/concepts/protocols#filter) caters to those use cases.
 
 ## Economic Spam Protection
 
-libp2p does not have strong spam protection guarantees, [RLN (Rate Limit Nullifier)](/overview/concepts/protocols#waku-rln-relay) is a protocol being developed by the Waku team towards this goal.
+libp2p does not have strong spam protection guarantees, [RLN (Rate Limit Nullifier)](/overview/concepts/protocols#rln-relay) is a protocol being developed by the Waku team towards this goal.

docs/overview/why-waku.md

@@ -1,6 +1,5 @@
 ---
 title: Why Waku?
-hide_table_of_contents: true
 ---
 
 Communication in the present day is heavily influenced by third-party intervention, ranging from censorship and deplatforming to intermediaries that seek to profit from rent and the misuse of data in the surveillance economy.

docs/powered-by-waku.mdx

@@ -14,21 +14,21 @@ import PoweredByCard from "@site/src/components/PoweredByCard";
 <div className="powered-by-card-container">
 	<PoweredByCard
 		appLink="https://status.im"
-		logoSrc="img/status-logo.svg"
+		logoSrc="/img/status-logo.svg"
 		logoAlt="Status icon"
 		>
 		Status is a secure messaging app, crypto wallet, and Web3 browser built with state-of-the-art technology.
 	</PoweredByCard>
 	<PoweredByCard
 		appLink="https://xmtp.org"
-		logoSrc="img/xmtp-logo.svg"
+		logoSrc="/img/xmtp-logo.svg"
 		logoAlt="XMTP icon"
 		>
 		XMTP uses the Waku network to enable secure Web3 messaging in their open protocol and network.
 	</PoweredByCard>
 	<PoweredByCard
 		appLink="https://railgun.org/"
-		logoSrc="img/railgun-logo.png"
+		logoSrc="/img/railgun-logo.png"
 		logoAlt="RAILGUN icon"
 		>
 		RAILGUN uses Waku to offer private gas payments to users, ensuring anonymity and privacy for their transactions.

docusaurus.config.js

@@ -59,7 +59,7 @@ const config = {
 				},
 				{
 					type: "dropdown",
-					label: "Waku Clients",
+					label: "Clients",
 					position: "right",
 					items: [
 						{
@@ -81,7 +81,13 @@ const config = {
 					to: "/community",
 					label: "Community",
 					position: "right"
-				}
+				},
+				{
+					href: "https://github.com/waku-org",
+					position: "right",
+					className: "header-github-link",
+					title: "Waku GitHub repository"
+				},
 			]
 		},
 		footer: {
@@ -149,7 +155,7 @@ const config = {
 							label: "Privacy Policy"
 						},
 						{
-							html: "<link rel='stylesheet' href='custom.css' />"
+							html: "<link rel='stylesheet' href='/custom.css' />"
 						}
 					]
 				}

static/custom.css

@@ -20,4 +20,22 @@
 	.powered-by-card-container {
 		grid-template-columns: repeat(3, 1fr);
 	}
+}
+
+.header-github-link:hover {
+	opacity: 0.6;
+}
+
+.header-github-link:before {
+	content: '';
+	width: 24px;
+	height: 24px;
+	display: flex;
+	background: url("data:image/svg+xml,%3Csvg viewBox='0 0 24 24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M12 .297c-6.63 0-12 5.373-12 12 0 5.303 3.438 9.8 8.205 11.385.6.113.82-.258.82-.577 0-.285-.01-1.04-.015-2.04-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729 1.205.084 1.838 1.236 1.838 1.236 1.07 1.835 2.809 1.305 3.495.998.108-.776.417-1.305.76-1.605-2.665-.3-5.466-1.332-5.466-5.93 0-1.31.465-2.38 1.235-3.22-.135-.303-.54-1.523.105-3.176 0 0 1.005-.322 3.3 1.23.96-.267 1.98-.399 3-.405 1.02.006 2.04.138 3 .405 2.28-1.552 3.285-1.23 3.285-1.23.645 1.653.24 2.873.12 3.176.765.84 1.23 1.91 1.23 3.22 0 4.61-2.805 5.625-5.475 5.92.42.36.81 1.096.81 2.22 0 1.606-.015 2.896-.015 3.286 0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12'/%3E%3C/svg%3E")
+    no-repeat;
+}
+
+html[data-theme='dark'] .header-github-link:before {
+	background: url("data:image/svg+xml,%3Csvg viewBox='0 0 24 24' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath fill='white' d='M12 .297c-6.63 0-12 5.373-12 12 0 5.303 3.438 9.8 8.205 11.385.6.113.82-.258.82-.577 0-.285-.01-1.04-.015-2.04-3.338.724-4.042-1.61-4.042-1.61C4.422 18.07 3.633 17.7 3.633 17.7c-1.087-.744.084-.729.084-.729 1.205.084 1.838 1.236 1.838 1.236 1.07 1.835 2.809 1.305 3.495.998.108-.776.417-1.305.76-1.605-2.665-.3-5.466-1.332-5.466-5.93 0-1.31.465-2.38 1.235-3.22-.135-.303-.54-1.523.105-3.176 0 0 1.005-.322 3.3 1.23.96-.267 1.98-.399 3-.405 1.02.006 2.04.138 3 .405 2.28-1.552 3.285-1.23 3.285-1.23.645 1.653.24 2.873.12 3.176.765.84 1.23 1.91 1.23 3.22 0 4.61-2.805 5.625-5.475 5.92.42.36.81 1.096.81 2.22 0 1.606-.015 2.896-.015 3.286 0 .315.21.69.825.57C20.565 22.092 24 17.592 24 12.297c0-6.627-5.373-12-12-12'/%3E%3C/svg%3E")
+    no-repeat;
 }